Open Stack

Not sure whether Zaqar is the best method for this (although I’m not saying
it isn’t yet).  Zaqar has a REST API, so it meets the “web centric”
requirement.  However, I believe Zaqar is meant to be a message queue for
end users, whereas a "notification system” would be for just
notifications.  It’s certainly possible to implement the latter over the
former, but I personally favor simple implementations, because simple is
usually easier to scale.

Also for the purpose of providing Openstack service notifications, coupling
the transport/mechanism for those service notifications with a message
queue service that can be used by customer applications would risk a denial
of service (whether malicious or not) for the service notifications.  This
isn’t necessarily just from malicious attacks, it could happen just by
having a really busy end user application for the message queue service.

- Min

On Thu, Apr 9, 2015 at 4:45 PM, Angus Salkeld <asalkeld at mirantis.com> wrote:

>
>
> 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:
>>> 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
>>
>>
>
> __________________________________________________________________________
> 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/13d476ba/attachment.html>