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> > 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] >>> Sent: Thursday, June 07, 2012 7:15 PM >>> To: 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> 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 Skype: nspollution t: @GeorgeReese p: +1.207.956.0217 enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese
