Hi Julien, I’m sending this mail regarding the generic alarm that Alexey Weyl from the Vitrage team is trying to implement in Aodh [1][2].
We understood that Aodh aims to be OpenStack alarming service, which is much more than an ‘engine of alarm evaluation’ (as you wrote in your comment in gerrit). If I may describe another use case for generic alarms - of OPNFV Doctor: A monitor notifies about an alarm, e.g. a NIC failure. The inspector (Vitrage in this case) receives the alarm, understands that the host is affected, and raises an alarm on the host. This is currently implemented by Vitrage calling nova force-down, and Nova sending a notification that is converted to an event and then consumed by an Aodh event-alarm. As the next phase in Doctor use case, for performance reasons, they might want Vitrage to raise alarms also on the instances and applications [3]. We know how to raise these alarms, and we can send them directly to a VNFM or another consumer. But we thought the right thing to do was to raise these alarms in Aodh, and let the VNFM connect to Aodh. This is what I mean by ‘Aodh as the alarming service of OpenStack’. What do you think about this use case? do you want Aodh to take this role, as the place where all OpenStack alarms are gathered and managed? Now, about the details. In his first commit, alexey_weyl suggested to add metadata, and you asked him to call it ‘userdata’. Personally, I think that metadata is more accurate. It is legitimate for an alarm to have additional data, in our example we need to hold the resource id and an external alarm id. When you call it userdata, it indeed sounds like ‘a user datastore’ (in your words), which is not the purpose at all. How about renaming it back to metadata? and how about adding it only to the generic alarm, instead of to all alarms? Waiting for your feedback :-) Ifat. [1] https://review.openstack.org/#/c/420409/ [2] https://review.openstack.org/#/c/413594/ [3] https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-January/014530.html __________________________________________________________________________ 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
