Open Stack

Good point that it’s already “multi-tiered”.  I thought ceilometer only
saved to database, I did not know it redistributes notifications.

As far as publishing to a “web native” protocol, I don’t have a particular
protocol in mind, as I said.  I’ve started looking at available protocols
to get an idea and have thus far come across just RSS, Atom, and WAMP.
WAMP seems like a good path for exposing a websocket based interface, but I
don’t have an idea of how widely it’s used and consumed.  I think it’s nice
that they have existing implementations for a wide range of client and
server targets.

I’m sure there are other protocols/stacks out there, it would be great to
hear from others as to what might be good targets.

- Min

On Thu, Apr 9, 2015 at 3:10 PM, gordon chung <gord at live.ca> 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.
> >
>
> just curious how the multi-tier approach differs from how it currently
> happens today? services today publish notifications to (multiple) message
> bus and a consumer (whether ceilometer or another service) pull in said
> notifications. from a ceilometer pov, we process said notifications and
> publish them to either a db, another queue, kafka, file, and/or http
> target. <disclaimer: another stupid question following> what web native
> protocols were you hoping to publish to -- apologies if this is common
> terminology.
>
> cheers,
>
> gord
>
> __________________________________________________________________________
> 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/88101055/attachment.html>