cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murali Reddy <>
Subject Re: Event Publish and Subscribe ( was perhaps Re: Cloudstack Questions )
Date Fri, 18 May 2012 13:00:57 GMT

Are there any use-cases for which it make sense to have publishers (that
use CloudStack API to publish) other than CloudStack? If its not overkill
we can have generic mechanism of publish/subscribe as service in
CloudStack. I can think of tenants workload VM's be able to leverage this
and publish something.

On 18/05/12 5:54 PM, "George Reese" <> wrote:

>Here's the way event pub sub should workĊ 
>People interested in events will subscribe to them via API and CloudStack
>will maintain a record that includes:
>* What type of event(s) the subscriber cares about
>* The URI of an endpoint to notify on events
>* An optional API key for signing event publications
>If you want it to be really rich, you allow for multiple notifications
>endpoints, including SMS and email.
>When the existing event management system in CloudStack identifies a
>state change, it published it to a message queue.
>A new CloudStack component is subscribed to the message queue and pulls
>the state change off. It then sends the event to all interested parties.
>It does not keep delivery state. It sends and forgets. The only thing
>resembling state is the counting of failures, eventually killing an
>endpoint that fails to often.
>On May 17, 2012, at 10:53 PM, Abhinandan Prateek wrote:
>> Cloudstack already have a well-defined set of events, currently being
>>used by the Usage module.
>> We can extend this to publish the events to registered
>> Nitin,
>>   We should evaluate the google guava package for this purpose.
>> -abhi
>>> -----Original Message-----
>>> From: Chiradeep Vittal []
>>> Sent: Saturday, May 12, 2012 3:48 AM
>>> To:
>>> Cc: Dean
>>> Subject: Re: Event Publish and Subscribe ( was perhaps Re: Cloudstack
>>> Questions )
>>> +1.
>>> This could also be used for example to update DNS records on a DNS
>>> whenever a VM is started / stopped in a network.
>>> A subscriber to the event bus can do this, and potentially things like
>>>updating a
>>> CMDB or an LDAP server.
>>> The important caveat is that this will be asynchronous to the stuff
>>> inside the management server: it has limited utility for doing stuff
>>>that  is
>>> required to succeed before an API operation can succeed.
>>> For example, if a VM start requires a NAT rule to be programmed on the
>>> firewall before the start can be considered successful. You could
>>>write a event
>>> bus subscriber that does this, but the management server would not
>>>know if
>>> it was successful or not.
>>> There's at least a couple of entry points:
>>> 1. Classes that implement this
>>>listener get
>>> notified on finite state event transitions. Examples include VM start
>>>/ stop 2.
>>> Classes that implement this
>>> get notified of network state transitions. Examples include adding
>>>nics and
>>> removing nics to/from a network.
>>> I think the first question regarding monitoring VMs on the isolated
>>>VLAN had a
>>> different origin though.
>>> The intention there was to have a monitoring service (e.g., Nagios)
>>>reach into
>>> the VM and monitor stuff like CPU, IO, or even applications.
>>> The issue there was around network reachability.
>>> --
>>> Chiradeep
>>> On 5/11/12 2:09 PM, "Adrian Cole" <> wrote:
>>>> +1
>>>> Makes sense to have pubsub.  Inside the java codebase, we could
>>>> consider a clean and idiomatic lib like guava which is easy to unit
>>>> Then, expose out-of-JVM hooks for any of the popular services people
>>>> -A
>>>> On May 11, 2012 1:58 PM, "Dean" <> wrote:
>>>>> Cross reference to:
>>> dev/201204.
>>>>> mbox/browser
>>>>> [ from: Marlon Davids ]
>>>>> < munch >
>>>>>> 2) How do we monitor VM's that are in Cloudstack when they are in
>>>>>> an
>>>>> isolated VLAN does
>>>>>> anyone have a clever workaround?
>>>>>> 3) Has anyone developed a script for parsing and alerting on
>>>>>> warning
>>>>> events in the
>>>>>> management Log yet?
>>>>> I would like to propose cloudstack consider a pub/sub model for event
>>>>> handling to complement API calls like listEvents.
>>>>> Polling can be problematic and sensitive to scaling.
>>>>> A simple example would be state change on a physical device.  The
>>>>> admin  server can simply publish a message on a network socket
>>>>> indicating that the  device has changed it's state.
>>>>> If a subscriber was interested in that device, it could make an api
>>>>> call  to the admin server for state change information for that
>>>>>device only.
>>>>> The
>>>>> admin server may choose to validate that physical device against the
>>>>> current state table in the database.
>>>>> The API would reply that this node changed it's state from
>>>>> Operational to  Prep For Maintenance.  (or whatever the transition
>>>>> state would be)
>>>>> The message exchange could be wrapped around vm states, resource
>>>>> additions/removals etc.
>>>>> Using a library like zeromq, a developer can write any number of
>>>>> consumers  in any language they wanted to subscribe to the Event Bus.
>>>>> Comments?
>>>>> --
>>>>> -Dean
>George Reese - Chief Technology Officer, enStratus
>e:    Skype: nspollution    t: @GeorgeReese
>p: +1.207.956.0217
>enStratus: Enterprise Cloud Management - @enStratus -
>To schedule a meeting with me:

View raw message