cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Reese <george.re...@enstratus.com>
Subject Re: Event Publish and Subscribe ( was perhaps Re: Cloudstack Questions )
Date Thu, 07 Jun 2012 19:48:51 GMT
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.Prateek@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.childers@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.Prateek@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.reese@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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message