<div dir="ltr"><p dir="ltr">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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>- Min</p>
<br><div class="gmail_quote">On Wed, Apr 8, 2015, 5:46 PM Halterman, Jonathan <<a href="mailto:jonathan.halterman@hp.com" target="_blank">jonathan.halterman@hp.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div>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).</div><div><br></div><div>Cheers,</div><div>Jonathan</div><div><br></div><span><div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-top-color:rgb(181,196,223)"><span style="font-weight:bold">From: </span> Vipul Sabhaya <<a href="mailto:vipuls@gmail.com" target="_blank">vipuls@gmail.com</a>><br><span style="font-weight:bold">Reply-To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a>><br><span style="font-weight:bold">Date: </span> Wednesday, April 8, 2015 at 5:18 PM<br><span style="font-weight:bold">To: </span> "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a>></div></span></div><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><span><div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-top-color:rgb(181,196,223)"><br><span style="font-weight:bold">Subject: </span> Re: [openstack-dev] [all] how to send messages (and events) to our    users<br></div></span></div><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><span><blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5"><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 8, 2015 at 4:45 PM, Min Pae <span dir="ltr">
<<a href="mailto:sputnik13@gmail.com" target="_blank">sputnik13@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><div><br></div></div></div><div>"an under-the-clould service" ? - That is not what I am after here. </div><div><br></div></div></div></div></blockquote></span><div>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.</div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>So is the yagi + atom hopper solution something we can point end-users to?</div><div>Is it per-tenant etc...</div></div></div></div></blockquote><div><br></div></span><div>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.<br></div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Sandy, do you have a write up somewhere on how to set this up so I can experiment a bit?</div><div><br></div><div>Maybe this needs to be a part of Cue?</div></div></div></div></blockquote><div><br></div></span><div>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).</div><span><font color="#888888"><div> </div></font></span></div></div></div></blockquote><div><br></div><div>Agree — I don’t think a multi-tenant notification service (which we seem to be after here) is the goal of Cue.</div><div><br></div><div>That said, Monasca <a href="https://wiki.openstack.org/wiki/Monasca" target="_blank">https://wiki.<u></u>openstack.org/wiki/Monasca</a> 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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888"><div>- Min</div></font></span></div></div></div><br>
______________________________<u></u>______________________________<u></u>______________<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.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br><br></blockquote></div><br></div></div></div></div></blockquote></span></div>
______________________________<u></u><u></u>______________________________<u></u><u></u>______________<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.<u></u>op<u></u>enstack.org?subject:<u></u>unsubscrib<u></u>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi<u></u>-bin/mailman/listinfo/<u></u>openstac<u></u>k-dev</a><br>
</blockquote></div></div>