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 <[email protected]> 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 <[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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
