Re: [openstack-dev] [heat][zaqar][telemetry] Subscribing to events

[McLellan, Steven]

On 11/28/16, 9:57 AM, "Zane Bitter"  wrote:

>On 28/10/16 08:32, Julien Danjou wrote:
>>> > 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.
>> That sounds easy. :)
>
>Not that easy: https://review.openstack.org/#/c/356404/
>
>oslo.messaging data is not supposed to be given out to users, so it has 
>to be sanitised before you can do so safely. I believe Searchlight has a 
>way of doing this. Mistral, as you can see from that patch, punted the 
>problem to the operator.


Searchlight for the most part discards everything except the payload (at least 
as far as an end-consumer is concerned). For some services we also restrict 
access to some information (Nova in particular has some fields that only 
administrators should have access to).


>
>I'd love to come up with some kind of cross-project approach to this (a 
>library?). I don't really care where people source their events from, 
>but if we're maintaining three different ways to do security-critical 
>access control for data produced independently by all of the different 
>OpenStack services, then we're headed for certain disaster.

I agree; we did it in Searchlight because there was no other option (and it 
took a long time to get traction for a self-contained project, let alone for a 
library that at the time would've had only one use case). We've been looking at 
having our listener process accept additional publishing endpoints (Zaqar being 
among them), but we'd certainly be open to make that sanitization code more 
reusable.

Steve
__
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

Re: [openstack-dev] [heat][zaqar][telemetry] Subscribing to events

[Zane Bitter]

On 28/10/16 08:32, Julien Danjou wrote:

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

That sounds easy. :)


Not that easy: https://review.openstack.org/#/c/356404/

oslo.messaging data is not supposed to be given out to users, so it has 
to be sanitised before you can do so safely. I believe Searchlight has a 
way of doing this. Mistral, as you can see from that patch, punted the 
problem to the operator.


I'd love to come up with some kind of cross-project approach to this (a 
library?). I don't really care where people source their events from, 
but if we're maintaining three different ways to do security-critical 
access control for data produced independently by all of the different 
OpenStack services, then we're headed for certain disaster.


cheers,
Zane.

__
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

Re: [openstack-dev] [heat][zaqar][telemetry] Subscribing to events

[Julien Danjou]

On Thu, Oct 27 2016, Fei Long Wang wrote:

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

Yeah I think the current thing is pretty simple IIRC, but since the
notifications are not really normalized, it's not very exciting to start
building filter. But I could see that happen. We just need to find a way
to express it correctly. Maybe some JSONPath thing in this regard that
we can use?

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

That sounds easy. :)

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

Not sure I do entirely follow, and I don't think Panko is concerned by
what you described (it only stores things). Can you be more precise? :)

-- 
Julien Danjou
-- Free Software hacker
-- https://julien.danjou.info


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [heat][zaqar][telemetry] Subscribing to events

[Fei Long Wang]

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  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: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
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

Re: [openstack-dev] [heat][zaqar][telemetry] Subscribing to events

[Thomas Herve]

On Tue, Oct 25, 2016 at 12:12 AM, Zane Bitter  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.

-- 
Thomas

__
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

Re: [openstack-dev] [heat][zaqar][telemetry] Subscribing to events

[Zane Bitter]

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.)



One question is whether we want to skip the subscription phase, and
simply makes all those events available to users at a known place (for
example, all events in the Zaqar queue events-queue, or maybe all Nova
events in the compute-events-queue). That pushes filtering to the
user, but it also simplifies the bootstrap phase.

Anyway, I wanted to send this before the summit so that people
interested can come talk to me.

Thanks,




__
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

[openstack-dev] [heat][zaqar][telemetry] Subscribing to events

[Thomas Herve]

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.

One question is whether we want to skip the subscription phase, and
simply makes all those events available to users at a known place (for
example, all events in the Zaqar queue events-queue, or maybe all Nova
events in the compute-events-queue). That pushes filtering to the
user, but it also simplifies the bootstrap phase.

Anyway, I wanted to send this before the summit so that people
interested can come talk to me.

Thanks,

-- 
Thomas

[1] 
http://docs.openstack.org/developer/heat/template_guide/environment.html#retrieving-events

[2] 
http://docs.openstack.org/developer/ceilometer/events.html#events-from-notifications

[3] https://github.com/therve/nabu

__
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