Open Stack

>  
> 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