On 28/06/13 4:28 AM, "Ryan Dietrich" <r...@betterservers.com> wrote:
>> 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.
>
>Yes, my assumption is you'd have to add another abstract method on
>BaseAsyncCmd to allow you to query for the UUID being modified.
>The problem with this is, many of the UUID's passed into commands are
>transformed into their internal ID (long) via the "Parameter" annotation.
>It would seem sort of ugly to have to re-query the UUID out of the
>database so it would be available when the job details needed to be
>published.
>
>Is there any way to get raw access to the parameters sent to a command?
>
>> 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.
>
>Ok, I'm working on this now.
>
>> 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.
>
>I will, I planned on using a configuration option to allow you to
>show/hide this extra information. I'll need it, but I understand that
>others might see this as bloat. (I'm making it default to "false").
>
>> 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.
>
>Sure, here's a couple quick examples.
>
>management-server.AlertEvent.ALERT-USAGE.*.* {"event":"ALERT.USAGE"}
>management-server.ResourceStateEvent.OperationSucceeded.Volume.bb213f8b-d7
>c8-4f7d-82bd-8e4ed230eb66
>{"id":"bb213f8b-d7c8-4f7d-82bd-8e4ed230eb66","old-state":"Snapshotting","n
>ew-state":"Ready","resource":"Volume"}
>management-server.ActionEvent.VM-CREATE.VirtualMachine.*
>{"status":"Scheduled","event":"VM.CREATE","account":"f66d4d60-bbdf-11e2-8b
>b5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}
>management-server.UsageEvent.VOLUME-DELETE.com-cloud-storage-Volume.dc802b
>ce-15f5-4694-be44-096d6aefca80
>{"id":"dc802bce-15f5-4694-be44-096d6aefca80","event":"VOLUME.DELETE","reso
>urce":"com.cloud.storage.Volume","account":"f66d4d60-bbdf-11e2-8bb5-525400
>14c04d","zone":"5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4"}
>
>So, within each EventCategory, things are consistent, but between them
>they are totally different. When using say, GSON as the parsing routine
>you're force to do one of two things when receiving messages.
>
>1. Look at the routing key with a regex or "indexOf" call to figure out
>what kind of message you're receiving.
>2. Create a superset object that has all of the possible keys that
>compose all of the messages, and then use GSON to slurp everything in.
>Then you'd have to just check which fields were NULL to figure out what
>type of message you're dealing with.
>
>Both of these solutions seem poor.
Okay. When I designed I did not think of somebody consuming the message
directly. Since it was framework to both publish and subscribe, I sort of
added the necessary details in the payload
(framework/events/src/org/apache/cloudstack/framework/events/Event.java)
that a callback ( registered through subscribe in
framework/events/src/org/apache/cloudstack/framework/events/EventBus.java).
Please go ahead and add the details to message body.
> Obviously a resource event is different than a usage event, but if they
>were at least consistent at some level I wouldn't have to have super
>explicit code paths for every type of message being sent. If I had to
>choose from any of the existing formats, I like the ResourceStateEvent
>the best. It clearly shows you what the type of the UUID (volume in the
>example) as well as the state change. ActionEvent, AlertEvent need some
>help.
You are right, since ResourceStateEvent is newly added its built up on
EventBus, but legacy events definitely need help.
>
>Lastly, UsageEvent. I'm almost confused what this means. Here's an
>example from my logs.
>
>management-server.ResourceStateEvent.DestroyRequested.Volume.ed51b63b-a63b
>-4e6a-8c36-45f32c29988d
>{"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","old-state":"Ready","new-stat
>e":"Destroy","resource":"Volume"}
>management-server.UsageEvent.VOLUME-DELETE.com-cloud-storage-Volume.ed51b6
>3b-a63b-4e6a-8c36-45f32c29988d
>{"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","event":"VOLUME.DELETE","reso
>urce":"com.cloud.storage.Volume","account":"f66d4d60-bbdf-11e2-8bb5-525400
>14c04d","zone":"5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4"}
>management-server.ResourceStateEvent.OperationSucceeded.Volume.ed51b63b-a6
>3b-4e6a-8c36-45f32c29988d
>{"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","old-state":"Destroy","new-st
>ate":"Destroy","resource":"Volume"}
>
>So, it would appear that three messages are generated when deleting a
>volume. A resource change, a usage event, and then a resource change
>confirmation. If I follow things up in the log, I see what triggers it.
>
>management-server.ActionEvent.VM-DESTROY.VirtualMachine.*
>{"status":"Scheduled","event":"VM.DESTROY","account":"f66d4d60-bbdf-11e2-8
>bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}
>
>Based on this, I'm not sure UsageEvent is actually adding any value.
>Worse, there is no way to tie the resource events to the action event
>that kicked those subordinate actions off.
I get the point. Its lot of noise on the message bus in default
configuration. Subscriber semantics permits that you subscribe to what are
you interested. Also each event has its own purpose. For e.g I could build
a totally de-coupled (from CloudStack) usage server for CloudStack just by
consuming usage events. Nevertheless its good to have flexibility. I
opened bug CLOUDSTACK-3272 to configure what events are published on the
event bus. Again this is a small fix, care to pick it up?
>
>Let me know how you'd like to proceed on these issues.
I already created the map of entity type for each event in the
'EventTypes' so adding this info is not a problem. Let me see if there is
a elegant way of getting entity UUID published for action event messages
as part of CLOUDSTACK-1673.
>
>-Ryan Dietrich
