On 27/06/13 5:46 AM, "Ryan Dietrich" <r...@betterservers.com> wrote:
>Hi, I'm doing some work in the event bus. My requirements are pretty >straightforward. > >1. Let me know when a command is executed. >2. Let me know the UUID of the element being modified when that command >is executed. (i.e.: If we're updating a virtual machine, the UUID should >be the one for that particular VM). For every api command, pretty much there is an action event generated that gets published on to event bus as well. CLOUDSTACK-3190 is open bug that needs to be fixed so that entity type being operated and UUID details of entity are published. It just tedious job to fix all the places action events are generated. Good pick for CloudStack newbie to fix it though. >3. When an async command is executed, let me know when it's started, and >every state change for that job until it is completed, and then let me >know what the status of the job is. This should be doable with a quick fix. I opened CLOUDSTACK-3233 for this. Would you mind take a look at this bug and see if you can fix it? I left details on what needs to be done in the bug. >4. I'd like to see the human readable username and domain of the user >that is executing the command. (I understand this one isn't as important >to many of you, a configuration option would suffice). >5. Lastly, I'd like to get state changes of the various components should >be sent to the event bus, again with the user/domanin/uuid. There is RESOURCE_STATE_CHANGE_EVENT's that get published on resource state change of critical entities VM, network, volume, snapshot. But there is entity type and entity UUID details only. If you feel user/domain details are needed as well please go ahead and fix message body. > >ActionEvent seems driven either directly, or via annotation >(api/src/com/cloud/event/ActionEvent.java), and relies on overrides to >get the actual description (not sure why there is a description there at >all actually). >The other "StateListener" / "StateEvent" systems seem totally unrelated, >yet encompass an alternative approach to writing messages to the event >bus (and have a bit more meta-data that I need). > >Are the things I'm looking to do the actual desired use case for the >event bus? Absolutely valid use cases. Please do bring out the feedback, we can at least fix it in 4.2. >Human readable descriptions aren't enough for me, I really need machine >consumable consistent messaging (currently it seems every message being >pushed out to RabbitMQ follows a different format). Is there any >documentation or plan for this system going forward? Event message body is key-value pair in JSON format. Body format may differ depending on the event category (action event, usage event, resource state change, alert). Can you please check if for a event category message are consistent? If its not please open bug. > >I need this working, now-ish, so I'm willing to get in and get it done, >but again, I'd rather work with the flow, and not against it :-) > >Cheers, > >-Ryan Dietrich > >On Jun 26, 2013, at 8:14 AM, Murali Reddy <murali.re...@citrix.com> wrote: > >> >> Yeah its a bug. Fixed CLOUDSTACK-3213 for both 4.2 and 4.1.1. Thanks for >> bringing it out. >> >> On 25/06/13 9:27 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote: >> >>> Thanks for the response. So am I to assume that the VM start/stop >>> showing up under EntityType Network is also a bug? >>> > >
