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, "[email protected]" <[email protected]> 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: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
