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.