Re: [openstack-dev] [Monasca] Locked (latched) alarms

[Hochmuth, Roland M]

Hi Witek, Thanks for the blueprint. We can review tomorrow if you would like. 
Personally, I like the term "locked". The alarm definition makes more sense 
(option 2). I don't think an operator will want to lock/latch an alarm 
sub-expression. The operator will want to lock/latch an entire alarm. 
Therefore, what seems to make sense is adding the new capability to the alarm 
definition as it applies to the entire alarm. We had a similar internal 
discussion a couple of months ago, and that is the same conclusion that we came 
too.

Regards --Roland







On 6/21/16, 4:38 AM, "witold.be...@est.fujitsu.com" 
 wrote:

>Hello everyone,
>
>I have written a short blueprint on locked/latched alarms for Monasca [1]. The 
>functionality allows the operator to define an alarm which after transition to 
>ALARM state, stays in that state until it is manually reset.
>
>What name should we use for that? Locked, lockable, latched, sticky? Something 
>else?
>
>I would also welcome feedback on a general implementation idea. Should we make 
>it in the same way as the deterministic alarms, by extending the 
>AlarmExpression? Or would it be enough to add the property to AlarmDefinition 
>(option 2)? I tend to the second solution. The change in the logic of 
>monasca-thresh would then be limited to AlarmThresholdingBolt. 
>evaluateThreshold as far as I understand. Craig and Roland, could you comment 
>on that please?
>
>
>Cheers
>Witek
>
>
>[1] https://blueprints.launchpad.net/monasca/+spec/locked-alarms
>
>
>Witold Bedyk
>Senior Software Engineer
>
>FUJITSU Enabling Software Technology GmbH
>Schwanthalerstr. 75a, 80336 München
>
>Telefon: +49 89 360908-547
>Telefax: +49 89 360908-8547
>COINS: 7941-6547
>
>Sitz der Gesellschaft: München
>AG München, HRB 143325
>Geschäftsführer: Dr. Yuji Takada, Hans-Dieter Gatzka, Christian Menk
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Monasca] Locked (latched) alarms

[witold.be...@est.fujitsu.com]

Hello everyone,

I have written a short blueprint on locked/latched alarms for Monasca [1]. The 
functionality allows the operator to define an alarm which after transition to 
ALARM state, stays in that state until it is manually reset.

What name should we use for that? Locked, lockable, latched, sticky? Something 
else?

I would also welcome feedback on a general implementation idea. Should we make 
it in the same way as the deterministic alarms, by extending the 
AlarmExpression? Or would it be enough to add the property to AlarmDefinition 
(option 2)? I tend to the second solution. The change in the logic of 
monasca-thresh would then be limited to AlarmThresholdingBolt. 
evaluateThreshold as far as I understand. Craig and Roland, could you comment 
on that please?


Cheers
Witek


[1] https://blueprints.launchpad.net/monasca/+spec/locked-alarms


Witold Bedyk
Senior Software Engineer

FUJITSU Enabling Software Technology GmbH
Schwanthalerstr. 75a, 80336 München

Telefon: +49 89 360908-547
Telefax: +49 89 360908-8547
COINS: 7941-6547

Sitz der Gesellschaft: München
AG München, HRB 143325
Geschäftsführer: Dr. Yuji Takada, Hans-Dieter Gatzka, Christian Menk


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev