cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murali Reddy <>
Date Tue, 17 Dec 2013 06:50:53 GMT


There may be mix up on the problem statement of the bug 3272. Sorry I did
not elaborate enough in the bug.

So there are multiple event types that are generated by CS, action events,
usage events, resource state change events and alerts. Current problem is
all the events gets published on the event bus when event bus is enabled.
Intent of the bug is to introduce global setting config parameters to
specify which category of events to be published or not be published on
the event bus. For e.g if global config param says to publish only usage
events, then only usage events should be published on the event bus.

If your intent is to create generic mechanism to add meta-data to events
that event bus can interpret and do specific action/configuration then it
might make sense to open a different bug and elaborate what you want to


On 16/12/13 1:11 PM, "Sonal Ojha" <> wrote:

>As per the problem statement the config parameters would be the deciding
>factor for the behavior of the events on the event bus. A subscriber would
>never decide the behavior , instead the publisher of the event would add
>config parameters to the events. On basis of these parameters the wrapper
>over the queue broker could decide the actions to be performed on the
>events. For example, the publisher of vm start event added a configuration
>parameter "expiry" to the event. On basis of this parameter the wrapper
>over the message queue broker would decide when should the vm start event
>be expired / deleted from the queue. The subscriber of the event will be
>able to read / fetch the event until its expired.
>There could be more than one config parameters attached to an event and so
>the proposal is to add all these config parameters into a Map instead of
>having only one config parameter added as a variable to the EventCategory
>On Fri, Dec 13, 2013 at 11:26 PM, Chiradeep Vittal <
>> wrote:
>>  Forgive me for my ignorance , why can't this be done by the client that
>> is receiving the events? Note that multiple clients can subscribe to the
>> event bus: this requirement is specific to one client?
>>   From: Sonal Ojha <>
>> Date: Wednesday, December 11, 2013 11:36 PM
>> To: Chiradeep Vittal <>
>> Cc: "" <>
>>   One of the use case be to delete only vm power on/off events from the
>> event queue, other be to persist all the update events on virtual
>> on the queue. The map of configuration parameters would be helpful to
>> decide such behaviors.
>> On Thu, Dec 12, 2013 at 3:26 AM, Chiradeep Vittal <
>>> wrote:
>>> Some more description of the use cases would be helpful. What is the
>>> point it is addressing?
>>> On 12/11/13 3:26 AM, "Sonal Ojha" <> wrote:
>>> >Hello,
>>> >
>>> >As per the description in the bug I would like to propose to
>>>introduce a
>>> >new instance variable configParameters of type HashMap to the
>>> >EventCategory
>>> >class.Currently, it could store one config parameter
>>> >""(key as String) and True (value as Boolean) but
>>> >later it could add more config parameters to change the behavior of
>>> >events.
>>> >
>>> >Thoughts / suggestions ?
>>> >
>>> >
>>> >--
>>> >
>>> >Thanks and Regards,
>>> >
>>>  >*Sonal Ojha* € Senior Engineer Product Development €  SunGard IT
>>>  >Availability
>>> >
>>> >Mobile +91-9922412645€ E-Mail:
>>  --
>> Thanks and Regards,
>> *Sonal Ojha* • Senior Engineer Product Development •  SunGard IT
>> Availability
>> Mobile +91-9922412645• E-Mail:
>Thanks and Regards,
>*Sonal Ojha* • Senior Engineer Product Development •  SunGard IT
>Mobile +91-9922412645• E-Mail:

View raw message