Open Stack

I would agree that the reason monasca had to roll their own notification
system is likely because one wasn't available, but whether that should be a
separate (stand alone separate project) vs integrated service (part of
something like monasca) is, to some extent, debatable.

No argument on the fact that this is a cross-cutting concern, and as
previous posts said it would be great to have a common mechanism for
publishing notifications to users.

Whether the notification system/service is separated or integrated, what
would be the best method to use?  Angus started the thread asking whether
such a service should be something that pushes to other existing endpoints
that the user supplies (syslog), or a publicly available message queue
(zaqar), and there was a suggestion to use something like AMQP as well.

I assert a public/user facing notification system should be web
centric/native for the reason I cited before, one of the consumers of such
a notification system will very likely be web browsers (perhaps even
horizon itself).  If there’s agreement on this point (which I guess there
isn’t, or nobody has really chimed in on it yet), then the next thing would
be to identify the best protocol/transport for communicating the
notifications.  I threw out Atom as a potential method, but by no means am
I advocating Atom, just that it be a web centric protocol.

Also, I’m of the mind that notification/event messaging there should be a
multi-tiered approach to notification/event messaging, where there’s
probably an internal message bus (be it rabbitmq, kafka, activemq, or what
have you) that all services publish to for consumption by other services,
and a consumer of said internal message bus that then publishes the events
publicly to users in a web native protocol.  BTW, I don’t mean open access
public, I mean public facing public.  There should still be access controls
on consuming the public facing notifications.

- Min

On Wed, Apr 8, 2015, 5:46 PM Halterman, Jonathan <jonathan.halterman at hp.com>
wrote:

> The ability to send general purpose notifications is clearly a
> cross-cutting concern. The absence of an AWS SNS like service in OpenStack
> is the reason that services like Monasca had to roll their own
> notifications. This has been a gaping hole in the OpenStack portfolio for a
> while, and I I think the right way to think of a solution is as a new
> service built around a pub/sub notification API (again, see SNS) as opposed
> to something which merely exposes OpenStack’s internal messaging
> infrastructure in some way (that would be inappropriate).
>
> Cheers,
> Jonathan
>
> From: Vipul Sabhaya <vipuls at gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Wednesday, April 8, 2015 at 5:18 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
>
> Subject: Re: [openstack-dev] [all] how to send messages (and events) to
> our users
>
> On Wed, Apr 8, 2015 at 4:45 PM, Min Pae <sputnik13 at gmail.com> wrote:
>
>>
>>
>>> "an under-the-clould service" ? - That is not what I am after here.
>>>
>>> I think the thread went off on a tangent and this point got lost.  A
>> user facing notification system absolutely should be a web centric
>> protocol, as I imagine one of the big consumers of such a system will be
>> monitoring dashboards which is trending more and more toward rich client
>> side “Single Page Applications”.  AMQP would not work well in such cases.
>>
>>
>>>
>>> So is the yagi + atom hopper solution something we can point end-users
>>> to?
>>> Is it per-tenant etc...
>>>
>>
>> While I haven’t seen it yet, if that solution provides a means to expose
>> the atom events to end users, it seems like a promising start.  The thing
>> that’s required, though, is authentication/authorization that’s tied in to
>> keystone, so that notification regarding a tenant’s resource is available
>> only to that tenant.
>>
>>
>>> Sandy, do you have a write up somewhere on how to set this up so I can
>>> experiment a bit?
>>>
>>> Maybe this needs to be a part of Cue?
>>>
>>
>> Sorry, Cue’s goal is to provision Message Queue/Broker services and
>> manage them, just like Trove provisions and manages databases.  Cue would
>> be ideally used to stand up and scale the RabbitMQ cluster providing
>> messaging for an application backend, but it does not provide messaging
>> itself (that would be Zaqar).
>>
>>
>
> Agree — I don’t think a multi-tenant notification service (which we seem
> to be after here) is the goal of Cue.
>
> That said, Monasca https://wiki.openstack.org/wiki/Monasca seems have
> implemented the collection, aggregation, and notification of these events.
> What may be missing is in Monasca is a mechanism for the tenant to consume
> these events via something other than AMQP.
>
>
>
>> - Min
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150409/465a9e79/attachment.html>