<div dir="ltr">Good point that it’s already “multi-tiered”.  I thought ceilometer only saved to database, I did not know it redistributes notifications.<div><br></div><div>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.<div><br></div><div>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.</div><div><br></div><div>- Min</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 3:10 PM, gordon chung <span dir="ltr"><<a href="mailto:gord@live.ca" target="_blank">gord@live.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
<br>
<br>
<br>
<br>
><br>
> I would agree that the reason monasca had to roll their own<br>
> notification system is likely because one wasn't available, but whether<br>
> that should be a separate (stand alone separate project) vs integrated<br>
> service (part of something like monasca) is, to some extent, debatable.<br>
><br>
> No argument on the fact that this is a cross-cutting concern, and as<br>
> previous posts said it would be great to have a common mechanism for<br>
> publishing notifications to users.<br>
><br>
> Whether the notification system/service is separated or integrated,<br>
> what would be the best method to use?  Angus started the thread asking<br>
> whether such a service should be something that pushes to other<br>
> existing endpoints that the user supplies (syslog), or a publicly<br>
> available message queue (zaqar), and there was a suggestion to use<br>
> something like AMQP as well.<br>
><br>
> I assert a public/user facing notification system should be web<br>
> centric/native for the reason I cited before, one of the consumers of<br>
> such a notification system will very likely be web browsers (perhaps<br>
> even horizon itself).  If there’s agreement on this point (which I<br>
> guess there isn’t, or nobody has really chimed in on it yet), then the<br>
> next thing would be to identify the best protocol/transport for<br>
> communicating the notifications.  I threw out Atom as a potential<br>
> method, but by no means am I advocating Atom, just that it be a web<br>
> centric protocol.<br>
><br>
> Also, I’m of the mind that notification/event messaging there should be<br>
> a multi-tiered approach to notification/event messaging, where there’s<br>
> probably an internal message bus (be it rabbitmq, kafka, activemq, or<br>
> what have you) that all services publish to for consumption by other<br>
> services, and a consumer of said internal message bus that then<br>
> publishes the events publicly to users in a web native protocol.  BTW,<br>
> I don’t mean open access public, I mean public facing public.  There<br>
> should still be access controls on consuming the public facing<br>
> notifications.<br>
><br>
<br>
</div></div>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.<br>
<br>
cheers,<br>
<br>
gord<br>
<div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>