Summarized requirements as per discussion in the forum at http://wiki.cloudstack.org/display/RelOps/Cloudstack+Events
Following are some items for which community opinion will help: 1. What should be used to classify messages (*topic*) - domain or account ? 2. Is there any differentiation between internal and external consumers ? Like authentication is easier for internal consumers. We can provide a different mechanism for internal consumption. 3. Authentication and authorization in a multi tenancy environment for the message consuming clients ? This becomes more important when pushing events, probably not now. Any other security concerns ? -abhi From: George Reese [mailto:george.re...@enstratus.com]<mailto:[mailto:george.re...@enstratus.com]> Sent: Friday, June 08, 2012 1:19 AM To: cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apache.org> Cc: Abhinandan Prateek Subject: Re: Event Publish and Subscribe ( was perhaps Re: Cloudstack Questions ) It also makes sense in a private cloud context as well. There's nothing different about public versus private on this matter, except the public cloud is going to have a lot more interested clients with the added burden of multi-tenancy management. #1 I think publishing to a MQ is a necessary first step, but it's not externally meaningful #2 I think pushing via notifications needs to be the end game. At enStratus right now, we are working on a notifications specification that hopefully will suit the needs of cloud platforms without being very difficult to implement. -George On Jun 7, 2012, at 2:37 PM, Chiradeep Vittal wrote: To George's earlier point about SNS, I think it makes a lot of sense in a public cloud where the end-users of the cloud want notifications (as opposed to the cloud operator). The feature should include access controls and scoping, independent of the actual transport. On 6/7/12 7:02 AM, "Abhinandan Prateek" <abhinandan.prat...@citrix.com<mailto:abhinandan.prat...@citrix.com>> wrote: Created a placeholder for this feature here in Jira http://bugs.cloudstack.org/browse/CS-15258 -----Original Message----- From: Chip Childers [mailto:chip.child...@sungard.com]<mailto:[mailto:chip.child...@sungard.com]> Sent: Thursday, June 07, 2012 7:15 PM To: cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apache.org> Cc: Chiradeep Vittal Subject: Re: Event Publish and Subscribe ( was perhaps Re: Cloudstack Questions ) On Thu, Jun 7, 2012 at 7:18 AM, Abhinandan Prateek <abhinandan.prat...@citrix.com<mailto:abhinandan.prat...@citrix.com>> wrote: Planning to use apache Qpid implementation of AMQP for publishing cloudstack events. +1 for implementing event notification via AMQP. This will be really helpful in more advanced deployment environments. It would also be great if the implementation was considered optional, because I think the standard deployment won't make use of this feature. +1 for using the Qpid Java Client. It supports 0-8, 0-9 and 0-10 AMQP specs, and they keep up with the AMQP spec development pretty well. That would give a deployment options for which broker they use (which might end up being RabbitMQ more often than not). I think that any CloudStack reference architectures (install guides, etc...) and testing should use QPID as the broker as well... the Java broker seems to be the best option for project level testing (Although we use the C++ broker internally). I'd also be very interested in hearing more about the topic and message taxonomy that you are thinking of implementing. I'm not able to sign the ICLA yet, but I'm more than happy to help work through the design for this functionality with you (on list of course). This is actually a pretty important bit of functionality in my environment. Thanks! -chip -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.com<mailto:george.re...@enstratus.com> Skype: nspollution t: @GeorgeReese p: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com<http://www.enstratus.com/> To schedule a meeting with me: http://tungle.me/GeorgeReese
