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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev