Open Stack

On 24/01/17 03:01 AM, Afek, Ifat (Nokia - IL) wrote:
> 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.
>

just curious, why doesn't vitrage send an event to aodh (on the error 
topic) in this case rather than get nova to do it? if you created an 
event alarm in aodh to check for vitrage error events could it solve the 
use case? i don't know if we store the event details but i imagine we 
could? or we could store the event id which can be linked to Panko 
(Event storage) for full metadata information?

tbh, i think the alarm history should be in panko since it seems like a 
pretty common use case to correlate an alarm event with the other events 
in the system.

> 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?

i had no idea what 'userdata' field was... i'd much prefer it be 
'metadata' even though it's a bit ambiguous.

cheers,
-- 
gord