10:37 a.m.
Hi
Before going too far down the BTM road, I just wanted to confirm whether or not we want
the business app, their components services, and their relationships to IT resources they
use, stored in Hawkular Inventory?
An alternative approach would be to derive the structure and relationships dynamically
from the business transaction instance information.
The benefit of storing in Inventory is it enables end users to navigate through the
inventory to understand the relationships to the business apps/services, as well as allow
other tooling (e.g. impact analysis) to determine the effect of IT resource downtime on
business apps.
Thoughts?
Regards
Gary
2:30 p.m.
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Tuesday, 31 March, 2015 10:37:53 AM
Subject: [Hawkular-dev] Business app/services representation in Inventory
Hi
Before going too far down the BTM road, I just wanted to confirm whether or
not we want the business app, their components services, and their
relationships to IT resources they use, stored in Hawkular Inventory?
Inventory definitely is the right place to store such information.
An alternative approach would be to derive the structure and
relationships
dynamically from the business transaction instance information.
Deriving the structure and relationships dynamically is basically
a "discovery" as called in ye olde RHQ days. That is a capability
which we'd very much like to keep.
The new inventory is (so far) unaware of special "discovery" step - everything
from resource creation to establishing relationships is done through 1 public
API that "anyone" can use.
The benefit of storing in Inventory is it enables end users to
navigate
through the inventory to understand the relationships to the business
apps/services, as well as allow other tooling (e.g. impact analysis) to
determine the effect of IT resource downtime on business apps.
+1. I know Brett will object that that's what Artificer is for, too, but I
personally see the difference in Inventory's focus on relationships, while
Artificer is more geared towards managing content.
Thoughts?
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2:53 p.m.
Ok thanks for the info.
Just to be clear - so as components are dynamically deployed/undeployed from a server,
these should be reflected in the Inventory - so it represents a current view of the
environment being managed?
Are there any plans to represent docker images in Inventory, associated with the servers
that have been launched using them?
Regards
Gary
----- Original Message -----
----- Original Message -----
> From: "Gary Brown" <gbrown(a)redhat.com>
> To: "Discussions around Hawkular development"
> <hawkular-dev(a)lists.jboss.org>
> Sent: Tuesday, 31 March, 2015 10:37:53 AM
> Subject: [Hawkular-dev] Business app/services representation in Inventory
>
> Hi
>
> Before going too far down the BTM road, I just wanted to confirm whether or
> not we want the business app, their components services, and their
> relationships to IT resources they use, stored in Hawkular Inventory?
>
Inventory definitely is the right place to store such information.
> An alternative approach would be to derive the structure and relationships
> dynamically from the business transaction instance information.
>
Deriving the structure and relationships dynamically is basically
a "discovery" as called in ye olde RHQ days. That is a capability
which we'd very much like to keep.
The new inventory is (so far) unaware of special "discovery" step -
everything
from resource creation to establishing relationships is done through 1 public
API that "anyone" can use.
> The benefit of storing in Inventory is it enables end users to navigate
> through the inventory to understand the relationships to the business
> apps/services, as well as allow other tooling (e.g. impact analysis) to
> determine the effect of IT resource downtime on business apps.
>
+1. I know Brett will object that that's what Artificer is for, too, but I
personally see the difference in Inventory's focus on relationships, while
Artificer is more geared towards managing content.
> Thoughts?
>
> Regards
> Gary
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:33 p.m.
On Tuesday, March 31, 2015 08:53:35 Gary Brown wrote:
Ok thanks for the info.
Just to be clear - so as components are dynamically deployed/undeployed from
a server, these should be reflected in the Inventory - so it represents a
current view of the environment being managed?
Are there any plans to represent docker images in Inventory, associated with
the servers that have been launched using them?
There are plans to only have a core set of predefined relationship types that
define most basic concepts (along with semantics) like "contains",
"defines",
etc. and a couple of data types:
* tenant
* environment (these two just to model the common structure of infrastructure)
* resource type
* metric type (metadata about resources or metrics, optional)
* resource
* metric
On top of the predefined relationship types, the user is free to create any
another relationship between any 2 entities. The semantics of those will be in
the hand of the user.
All will be dynamically creatable and amendable so if you wish to create a
resource representing a docker image, go ahead.
Things will probably get a little bit more complicated at the UI level for how
to represent things but data model wise, we won't care what the inventory
stores.
Regards
Gary
----- Original Message -----
> ----- Original Message -----
>
> > From: "Gary Brown" <gbrown(a)redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev(a)lists.jboss.org>
> > Sent: Tuesday, 31 March, 2015 10:37:53 AM
> > Subject: [Hawkular-dev] Business app/services representation in
> > Inventory
> >
> > Hi
> >
> > Before going too far down the BTM road, I just wanted to confirm whether
> > or
> > not we want the business app, their components services, and their
> > relationships to IT resources they use, stored in Hawkular Inventory?
>
> Inventory definitely is the right place to store such information.
>
> > An alternative approach would be to derive the structure and
> > relationships
> > dynamically from the business transaction instance information.
>
> Deriving the structure and relationships dynamically is basically
> a "discovery" as called in ye olde RHQ days. That is a capability
> which we'd very much like to keep.
>
> The new inventory is (so far) unaware of special "discovery" step -
> everything
> from resource creation to establishing relationships is done through 1
> public API that "anyone" can use.
>
> > The benefit of storing in Inventory is it enables end users to navigate
> > through the inventory to understand the relationships to the business
> > apps/services, as well as allow other tooling (e.g. impact analysis) to
> > determine the effect of IT resource downtime on business apps.
>
> +1. I know Brett will object that that's what Artificer is for, too, but I
> personally see the difference in Inventory's focus on relationships, while
> Artificer is more geared towards managing content.
>
> > Thoughts?
> >
> > Regards
> > Gary
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1:54 p.m.
Catching up on old emails...
On 03/31/2015 02:53 PM, Gary Brown wrote:
Ok thanks for the info.
Just to be clear - so as components are dynamically deployed/undeployed from a server,
these should be reflected in the Inventory - so it represents a current view of the
environment being managed?
This is an important point.
When a resource in deployed / undeployed / deployed (or redeployed), you
want to know if it's there but you also want to keep historical data
(say response time history before the redeployment).
It also has an impact on alerts, if an app is undeployed legitimately
you don't want to receive 'non-available' alerts but you want them back
once the app is deployed...
Are there any plans to represent docker images in Inventory,
associated with the servers that have been launched using them?
It should become available in the UI, but will it come directly from
Kubernetes (when available) ? Synched with Kubernetes ? I don't know,
we'll tackle this later.
Thomas
Regards
Gary
----- Original Message -----
> ----- Original Message -----
>> From: "Gary Brown" <gbrown(a)redhat.com>
>> To: "Discussions around Hawkular development"
>> <hawkular-dev(a)lists.jboss.org>
>> Sent: Tuesday, 31 March, 2015 10:37:53 AM
>> Subject: [Hawkular-dev] Business app/services representation in Inventory
>>
>> Hi
>>
>> Before going too far down the BTM road, I just wanted to confirm whether or
>> not we want the business app, their components services, and their
>> relationships to IT resources they use, stored in Hawkular Inventory?
>>
>
> Inventory definitely is the right place to store such information.
>
>> An alternative approach would be to derive the structure and relationships
>> dynamically from the business transaction instance information.
>>
>
> Deriving the structure and relationships dynamically is basically
> a "discovery" as called in ye olde RHQ days. That is a capability
> which we'd very much like to keep.
>
> The new inventory is (so far) unaware of special "discovery" step -
> everything
> from resource creation to establishing relationships is done through 1 public
> API that "anyone" can use.
>
>> The benefit of storing in Inventory is it enables end users to navigate
>> through the inventory to understand the relationships to the business
>> apps/services, as well as allow other tooling (e.g. impact analysis) to
>> determine the effect of IT resource downtime on business apps.
>>
>
> +1. I know Brett will object that that's what Artificer is for, too, but I
> personally see the difference in Inventory's focus on relationships, while
> Artificer is more geared towards managing content.
>
>> Thoughts?
>>
>> Regards
>> Gary
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:22 p.m.
On 4/15/2015 7:54 AM, Thomas Heute wrote:
Catching up on old emails...
On 03/31/2015 02:53 PM, Gary Brown wrote:
> Ok thanks for the info.
>
> Just to be clear - so as components are dynamically deployed/undeployed from a
server, these should be reflected in the Inventory - so it represents a current view of
the environment being managed?
This is an important point.
When a resource in deployed / undeployed / deployed (or redeployed), you
want to know if it's there but you also want to keep historical data
(say response time history before the redeployment).
It also has an impact on alerts, if an app is undeployed legitimately
you don't want to receive 'non-available' alerts but you want them back
once the app is deployed...
This could be relevant if avail is reported from an external monitor,
like the pinger. It either needs to be aware of the redeploy, or aware
of some maintenance window, I think, in order to not report DOWN avail.
Maybe easier is to let the down avail be reported but instead mute the
Triggers. If Triggers are logically connected to Resources then we may
want to disable the triggers during certain resource-level events, like
a maintenance window or a scheduled redeploy operation. In RHQ I think
people liked to see down avail reported for a resource when it was down
for a redeploy. If we could optionally disable alerting then that would
be nice.
Another possibility could maybe be to add some sort of validation action
on a trigger, or maybe some sort of callback, such that persistence and
further actions are ignored if validation does not pass. So, instead of
preventing the triggering up front, we could mute it in a
post-processing way.
5:58 p.m.
Couldn't the deployment status be added to the trigger when relevant, e.g. avail =
DOWN && deployment_status = DEPLOYED - if user wants to ignore DOWN notifications
when in maintenance mode.
Reason being that something checking the end to end availability of a linked (dependent)
set of resources would want to know if a resource was down, regardless of whether it was
in maintenance, as it impacts the higher level business app. So it may be on a case by
case basis - so possibly best left to the trigger definition to determine if deployment
status is relevant?
Regards
Gary
----- Original Message -----
On 4/15/2015 7:54 AM, Thomas Heute wrote:
> Catching up on old emails...
>
> On 03/31/2015 02:53 PM, Gary Brown wrote:
>> Ok thanks for the info.
>>
>> Just to be clear - so as components are dynamically deployed/undeployed
>> from a server, these should be reflected in the Inventory - so it
>> represents a current view of the environment being managed?
> This is an important point.
>
> When a resource in deployed / undeployed / deployed (or redeployed), you
> want to know if it's there but you also want to keep historical data
> (say response time history before the redeployment).
>
> It also has an impact on alerts, if an app is undeployed legitimately
> you don't want to receive 'non-available' alerts but you want them back
> once the app is deployed...
This could be relevant if avail is reported from an external monitor,
like the pinger. It either needs to be aware of the redeploy, or aware
of some maintenance window, I think, in order to not report DOWN avail.
Maybe easier is to let the down avail be reported but instead mute the
Triggers. If Triggers are logically connected to Resources then we may
want to disable the triggers during certain resource-level events, like
a maintenance window or a scheduled redeploy operation. In RHQ I think
people liked to see down avail reported for a resource when it was down
for a redeploy. If we could optionally disable alerting then that would
be nice.
Another possibility could maybe be to add some sort of validation action
on a trigger, or maybe some sort of callback, such that persistence and
further actions are ignored if validation does not pass. So, instead of
preventing the triggering up front, we could mute it in a
post-processing way.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:18 p.m.
It certainly could be. As I mentioned below, I agree that users want to
see DOWN avail during redeploy, they just don't want to see an alert.
If we incorporate deployment_status into the data being fed to alerting
then we can do this sort of alerting. Although, I'm not positive that
we want to report deployment_status in that way. I think given
reporting intervals we may encounter some edge cases.
On 4/15/2015 11:58 AM, Gary Brown wrote:
Couldn't the deployment status be added to the trigger when
relevant, e.g. avail = DOWN && deployment_status = DEPLOYED - if user wants to
ignore DOWN notifications when in maintenance mode.
Reason being that something checking the end to end availability of a linked (dependent)
set of resources would want to know if a resource was down, regardless of whether it was
in maintenance, as it impacts the higher level business app. So it may be on a case by
case basis - so possibly best left to the trigger definition to determine if deployment
status is relevant?
Regards
Gary
----- Original Message -----
>
> On 4/15/2015 7:54 AM, Thomas Heute wrote:
>> Catching up on old emails...
>>
>> On 03/31/2015 02:53 PM, Gary Brown wrote:
>>> Ok thanks for the info.
>>>
>>> Just to be clear - so as components are dynamically deployed/undeployed
>>> from a server, these should be reflected in the Inventory - so it
>>> represents a current view of the environment being managed?
>> This is an important point.
>>
>> When a resource in deployed / undeployed / deployed (or redeployed), you
>> want to know if it's there but you also want to keep historical data
>> (say response time history before the redeployment).
>>
>> It also has an impact on alerts, if an app is undeployed legitimately
>> you don't want to receive 'non-available' alerts but you want them
back
>> once the app is deployed...
> This could be relevant if avail is reported from an external monitor,
> like the pinger. It either needs to be aware of the redeploy, or aware
> of some maintenance window, I think, in order to not report DOWN avail.
> Maybe easier is to let the down avail be reported but instead mute the
> Triggers. If Triggers are logically connected to Resources then we may
> want to disable the triggers during certain resource-level events, like
> a maintenance window or a scheduled redeploy operation. In RHQ I think
> people liked to see down avail reported for a resource when it was down
> for a redeploy. If we could optionally disable alerting then that would
> be nice.
>
> Another possibility could maybe be to add some sort of validation action
> on a trigger, or maybe some sort of callback, such that persistence and
> further actions are ignored if validation does not pass. So, instead of
> preventing the triggering up front, we could mute it in a
> post-processing way.
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:26 a.m.
Hi
----- Original Message -----
It certainly could be. As I mentioned below, I agree that users want to see
DOWN avail during redeploy, they just don't want to see an alert. If we
incorporate deployment_status into the data being fed to alerting then we
can do this sort of alerting. Although, I'm not positive that we want to
report deployment_status in that way. I think given reporting intervals we
may encounter some edge cases.
I was thinking that the deployment status for the expression could be retrieved from
inventory/cached data rather than be part of the metric. Is that possible?
Regards
Gary
On 4/15/2015 11:58 AM, Gary Brown wrote:
Couldn't the deployment status be added to the trigger when relevant, e.g.
avail = DOWN && deployment_status = DEPLOYED - if user wants to ignore DOWN
notifications when in maintenance mode.
Reason being that something checking the end to end availability of a linked
(dependent) set of resources would want to know if a resource was down,
regardless of whether it was in maintenance, as it impacts the higher level
business app. So it may be on a case by case basis - so possibly best left
to the trigger definition to determine if deployment status is relevant?
Regards
Gary
----- Original Message -----
On 4/15/2015 7:54 AM, Thomas Heute wrote:
Catching up on old emails...
On 03/31/2015 02:53 PM, Gary Brown wrote:
Ok thanks for the info.
Just to be clear - so as components are dynamically deployed/undeployed
from a server, these should be reflected in the Inventory - so it
represents a current view of the environment being managed?
This is an important point.
When a resource in deployed / undeployed / deployed (or redeployed), you
want to know if it's there but you also want to keep historical data
(say response time history before the redeployment).
It also has an impact on alerts, if an app is undeployed legitimately
you don't want to receive 'non-available' alerts but you want them back
once the app is deployed...
This could be relevant if avail is reported from an external monitor,
like the pinger. It either needs to be aware of the redeploy, or aware
of some maintenance window, I think, in order to not report DOWN avail.
Maybe easier is to let the down avail be reported but instead mute the
Triggers. If Triggers are logically connected to Resources then we may
want to disable the triggers during certain resource-level events, like
a maintenance window or a scheduled redeploy operation. In RHQ I think
people liked to see down avail reported for a resource when it was down
for a redeploy. If we could optionally disable alerting then that would
be nice.
Another possibility could maybe be to add some sort of validation action
on a trigger, or maybe some sort of callback, such that persistence and
further actions are ignored if validation does not pass. So, instead of
preventing the triggering up front, we could mute it in a
post-processing way.
_______________________________________________
hawkular-dev mailing list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:03 p.m.
On 15 Apr 2015, at 20:18, Jay Shaughnessy wrote:
It certainly could be. As I mentioned below, I agree that users want
to see DOWN avail during redeploy, they just don't want to see an
alert. If we incorporate deployment_status into the data being fed to
alerting then we can do this sort of alerting. Although, I'm not
positive that we want to report deployment_status in that way. I
think given reporting intervals we may encounter some edge cases
This "deployment_status" could be another value in the resource
state like "maintenance mode" - perhaps "re-deploying" or such.
See also "Computed resource state" email(s)
http://lists.jboss.org/pipermail/hawkular-dev/2015-March/000413.html
8:39 p.m.
----- Original Message -----
----- Original Message -----
> From: "Gary Brown" <gbrown(a)redhat.com>
> To: "Discussions around Hawkular development"
> <hawkular-dev(a)lists.jboss.org>
> Sent: Tuesday, 31 March, 2015 10:37:53 AM
> Subject: [Hawkular-dev] Business app/services representation in Inventory
>
> Hi
>
> Before going too far down the BTM road, I just wanted to confirm whether or
> not we want the business app, their components services, and their
> relationships to IT resources they use, stored in Hawkular Inventory?
>
Inventory definitely is the right place to store such information.
> An alternative approach would be to derive the structure and relationships
> dynamically from the business transaction instance information.
>
Deriving the structure and relationships dynamically is basically
a "discovery" as called in ye olde RHQ days. That is a capability
which we'd very much like to keep.
+1 Very powerful and important in getting a great user experience.
The new inventory is (so far) unaware of special "discovery" step -
everything
from resource creation to establishing relationships is done through 1 public
API that "anyone" can use.
> The benefit of storing in Inventory is it enables end users to navigate
> through the inventory to understand the relationships to the business
> apps/services, as well as allow other tooling (e.g. impact analysis) to
> determine the effect of IT resource downtime on business apps.
>
+1. I know Brett will object that that's what Artificer is for, too, but I
personally see the difference in Inventory's focus on relationships, while
Artificer is more geared towards managing content.
> Thoughts?
>
> Regards
> Gary
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:36 p.m.
On 31 Mar 2015, at 20:39, John Doyle wrote:
> Deriving the structure and relationships dynamically is
basically
> a "discovery" as called in ye olde RHQ days. That is a capability
> which we'd very much like to keep.
+1 Very powerful and important in getting a great user experience.
Just to make this a bit more explicit: for Hawkular we want not only
discover and represent the classic parent-child relations like
"WildFly running on JVM on RHEL", but also discover that e.g. a couple
of WildFly servers (or apps) use the same JDBC url, so they are most
likely to form an application that is clustered. Similarly for joint
Caches / JGroups / messaging infrastructure.
3:33 p.m.
Hi,
On 31 Mar 2015, at 10:37, Gary Brown wrote:
whether or not we want the business app, their components services,
and their relationships to IT resources they use, stored in Hawkular
Inventory?
Yes. We need to still decide though what kind of resources we
want to store and represent. One of the confusing aspects of RHQ (UI)
was that we basically did our job too good and showed too much.
3297
days inactive
3313
days old
12 comments
6 participants
participants (6)
-
Gary Brown -
Heiko W.Rupp -
Jay Shaughnessy -
John Doyle -
Lukas Krejci -
Thomas Heute