cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: Event Publish and Subscribe ( was perhaps Re: Cloudstack Questions )
Date Thu, 07 Jun 2012 19:37:52 GMT
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" <>

>Created a placeholder for this feature here in Jira
>>-----Original Message-----
>>From: Chip Childers []
>>Sent: Thursday, June 07, 2012 7:15 PM
>>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
>><> 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
>>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
>>seems to be the best option for project level testing (Although we use
>>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.

View raw message