> 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-d7c8-4f7d-82bd-8e4ed230eb66
{"id":"bb213f8b-d7c8-4f7d-82bd-8e4ed230eb66","old-state":"Snapshotting","new-state":"Ready","resource":"Volume"}
management-server.ActionEvent.VM-CREATE.VirtualMachine.*
{"status":"Scheduled","event":"VM.CREATE","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}
management-server.UsageEvent.VOLUME-DELETE.com-cloud-storage-Volume.dc802bce-15f5-4694-be44-096d6aefca80
{"id":"dc802bce-15f5-4694-be44-096d6aefca80","event":"VOLUME.DELETE","resource":"com.cloud.storage.Volume","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","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. 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.
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-state":"Destroy","resource":"Volume"}
management-server.UsageEvent.VOLUME-DELETE.com-cloud-storage-Volume.ed51b63b-a63b-4e6a-8c36-45f32c29988d
{"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","event":"VOLUME.DELETE","resource":"com.cloud.storage.Volume","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","zone":"5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4"}
management-server.ResourceStateEvent.OperationSucceeded.Volume.ed51b63b-a63b-4e6a-8c36-45f32c29988d
{"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","old-state":"Destroy","new-state":"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-8bb5-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.
Let me know how you'd like to proceed on these issues.
-Ryan Dietrich
