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 <[email protected]> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> Date: Wednesday, April 8, 2015 at 5:18 PM To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> 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 <[email protected]> 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: [email protected]?subject:unsubscribe >> <http://[email protected]?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
