Open Stack

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.bedyk at est.fujitsu.com" <witold.bedyk at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev