Re: [Hawkular-dev] Business app/services representation in Inventory

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