Hello Murali, I have started working on the changes required to control publishing of events on the event bus based on the event category config parameter. While working on the changes I could come across the following approach
a.) Changed the routing key and binding key format to the following adding the boolean eventCategoryConfig. The changes to the routing key are meant for the re-connection logic to the AMQP server in case of loss of connection, file RabbitMQEventBus.java function ReconnectionTask s eventSource.eventCategory.eventType.resourceType.resourceUuid. *eventCategoryConfig* I am attaching the patch with the email kindly let me know your comments. For now, the evtn category configuration parameter is hard coded (default to True) when the EventCategory object is instantiated, I am working to move it out to a configuration file. Any suggestions? > > ---------- Forwarded message ---------- > From: Murali Reddy <murali.re...@citrix.com> > Date: Tue, Dec 17, 2013 at 12:20 PM > Subject: Re: [DISCUSS][PROPOSAL] (CLOUDSTACK-3272) > To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>, Chiradeep > Vittal <chiradeep.vit...@citrix.com> > > > > Sonal, > > 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 > address. > > Thanks, > Murali > > > On 16/12/13 1:11 PM, "Sonal Ojha" <sonal.o...@sungard.com> 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 > >class. > > > > > >On Fri, Dec 13, 2013 at 11:26 PM, Chiradeep Vittal < > >chiradeep.vit...@citrix.com> 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 <sonal.o...@sungard.com> > >> Date: Wednesday, December 11, 2013 11:36 PM > >> To: Chiradeep Vittal <chiradeep.vit...@citrix.com> > >> Cc: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> > >> Subject: Re: [DISCUSS][PROPOSAL] (CLOUDSTACK-3272) > >> > >> 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 > >>machines > >> 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 < > >> chiradeep.vit...@citrix.com> wrote: > >> > >>> Some more description of the use cases would be helpful. What is the > >>>pain > >>> point it is addressing? > >>> > >>> On 12/11/13 3:26 AM, "Sonal Ojha" <sonal.o...@sungard.com> 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 > >>> >"publish.action.events"(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* EURO Senior Engineer Product Development EURO SunGard IT > >>> >Availability > >>> > > >>> >Mobile +91-9922412645 EURO E-Mail: sonal.o...@sungard.com > >>> > >>> > >>> > >> > >> > >> -- > >> > >> Thanks and Regards, > >> > >> *Sonal Ojha* * Senior Engineer Product Development * SunGard IT > >> Availability > >> > >> Mobile +91-9922412645* E-Mail: sonal.o...@sungard.com > >> > > > > > > > >-- > > > >Thanks and Regards, > > > >*Sonal Ojha* * Senior Engineer Product Development * SunGard IT > >Availability > > > >Mobile +91-9922412645* E-Mail: sonal.o...@sungard.com > > > > > > -- Thanks and Regards, *Sonal Ojha* * Senior Engineer Product Development * SunGard IT Availability Mobile +91-9922412645* E-Mail: sonal.o...@sungard.com
