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 <[email protected]> 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: [email protected]
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--------------------------------------------------------------------------
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
