Open Stack

Firstly, thank you for bring this topic up, therve.

IMHO, there are some requirements can't be met(or need to be confirmed 
by Aodh team) by Aodh for this case.

1. Granularity
     For Aodh event alarm, user can only define the alarm based on a 
particular event(Pls correct me). However, Personally I would like to 
see a flexible 'filter' for the notifications.

2. Content Format
     The info/data forwarded by Aodh is alarm, not the original event. 
At here, I assume most of the users would like to see the original 
event, not the alarm.

And it triggers me another idea. Recently, I'm playing with 
Ceilometer/Aodh a lot. The idea is, let Panko support event filter 
before dispatching. Currently, Panko/Ceilometer is using two yaml files 
to define the event related options. We can still keep it and meanwhile 
adding a per tenant, persistent filter in DB as user's customized 
options. It won't break the backward compatibility. Julien, LiuSheng, 
does that make any sense? Thanks.


On 26/10/16 02:48, Thomas Herve wrote:
> On Tue, Oct 25, 2016 at 12:12 AM, Zane Bitter <zbitter at redhat.com> wrote:
>> On 22/10/16 10:38, Thomas Herve wrote:
>>> Hi all,
>>>
>>> One of my long time goal since I started contributing to OpenStack is
>>> to try to remove polling where I can. With Zaqar WebSocket support, we
>>> now have a transport available for users to connect to, and where we
>>> can push notifications. We already leveraged that in Heat [1], so that
>>> you can manipulate a stack and you'll be notified when its status
>>> changes.
>>>
>>> Still, not everyone uses Heat, and under the hood it still polls for
>>> you. We should be able to use the various notifications that projects
>>> publish to push similar events. Ceilometer already consumes those
>>> notifications and try to make them somewhat consumable [2].
>>>
>>> The missing piece is something that bridges Ceilometer and Zaqar. I
>>> wrote a small service [3] which provide a simple API, so that you can
>>> say "Subscribe to those events and send them to this queue". The data
>>> flow looks like this:
>>>
>>> Service (Nova, Neutron) -> Notification -> Ceilometer -> Bridge ->
>>> Zaqar -> User.
>>>
>>> This way, you'll get a Zaqar message per event, with some filtering
>>> done by the bridge service. It's far from being ideal, as the
>>> notification format is a endless topic of conversation, but I hope
>>> that if we start using it things will move further. I also hope I can
>>> get some feedback on the approach.
>>
>> Could you document what makes this different from
>> http://docs.openstack.org/developer/aodh/event-alarm.html? (I can think of
>> some ways, but it's not clear to me whether a separate service is the right
>> thing or if the existing Aodh event alarms can be modified to do what we
>> want.)
> Asking the tough questions :). I don't know about the details, but
> it's possible that since https://review.openstack.org/#/c/335289/ got
> merged, you have the same possibilities nowadays. I'd need to test it,
> in which case my service is not necessary anymore (though the other
> questions still apply). But in terms of semantics, it feels a bit
> weird to use alarming for continuous event retrieval.
>

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--------------------------------------------------------------------------