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 to subscribers.
On 18/05/12 5:54 PM, "George Reese" <george.re...@enstratus.com> 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. > >-George
