Open Stack

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://OpenStack-dev-request@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/8b78a37f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5517 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150409/8b78a37f/attachment.bin>