Open Stack

On Fri, Apr 10, 2015 at 2:27 AM, Min Pae <sputnik13 at gmail.com> wrote:

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

No argument here with what you said. The question is can everyone get
behind Zaqar or do we need something else?

-Angus


> - 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:unsubscrib
>> e
>> 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/20150410/abcbf8cc/attachment.html>