Hi, list:
First, please pardon me for some rant.
<rant>
I have been using cloudstack rabbitmq events to integrate with external apps
since 4.3.x. Recently we upgraded to CS 4.5.1 and noticed that CS 4.5 events
are quite different from 4.3 events, at least for ones we are working with (for
VM.CREATE and VM.DESTROY events, both the routing key and the event message are
now different).
I have not found any documentation on such changes. If event notification
framework is intended as an integration point with external apps, I would have
expected a stable and backward compatible interface to cloudstack events over
upgrades, just like any other cloudstack API’s. How can such changes be
introduced and not documented in release notes?
</rant>
While working with VM.CREATE and VM.DESTROY events (for CS 4.5.1), I noticed
some weirdness of the messages when parsing them as JSON object. Here is an
example:
{
"cmdInfo":
"{\"response\":\"json\",\"id\":\"b780c229-7064-47e5-97d0-a8b4590b36b8\",\"sessionkey\":\"WY6E5WuM8SbqMw4bCumnVgGsgEQ\\u003d\",\"ctxDetails\":\"{\\\"com.cloud.vm.VirtualMachine\\\":\\\"b780c229-7064-47e5-97d0-a8b4590b36b8\\\"}\",\"cmdEventType\":\"VM.DESTROY\",\"ctxUserId\":\"2\",\"httpmethod\":\"GET\",\"_\":\"1438027779033\",\"uuid\":\"b780c229-7064-47e5-97d0-a8b4590b36b8\",\"ctxAccountId\":\"2\",\"ctxStartEventId\":\"6282\"}",
"instanceType": "VirtualMachine",
"instanceUuid": "b780c229-7064-47e5-97d0-a8b4590b36b8",
"jobId": "61a62e5d-61ee-41eb-b947-0f8ef5d857c3",
"status": "SUCCEEDED",
"processStatus": "0",
"commandEventType": "VM.DESTROY",
"resultCode": "0",
"command": "org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin",
"jobResult":
"org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/{\"id\":\"b780c229-7064-47e5-97d0-a8b4590b36b8\",\"name\":\"yz-x1\",\"displayname\":\"yz-x1\",\"account\":\"admin\",\"domainid\":\"994ff03e-bb8f-11e4-b7d5-36d1d14da5e9\",\"domain\":\"ROOT\",\"created\":\"2015-07-27T12:01:12-0500\",\"state\":\"Destroyed\",\"haenable\":false,\"zoneid\":\"1b0b4859-7b8a-41dd-8522-4dbf24345509\",\"zonename\":\"sjlab\",\"templateid\":\"e6fa410f-4bf0-4b3c-9982-9d60e7ffc07e\",\"templatename\":\"Base\",\"templatedisplaytext\":\"Base
with 32 GB root and
cloud-init\",\"passwordenabled\":false,\"serviceofferingid\":\"11a5e901-bc78-45c6-8b81-a2a9e3530164\",\"serviceofferingname\":\"[email protected]@1.5GB\",\"cpunumber\":1,\"cpuspeed\":1000,\"memory\":1536,\"cpuused\":\"0.56%\",\"networkkbsread\":0,\"networkkbswrite\":2,\"diskkbsread\":2670,\"diskkbswrite\":163,\"diskioread\":0,\"diskiowrite\":0,\"guestosid\":\"a0c75a5b-bb8f-11e4-b7d5-36d1d14da5e9\",\"rootdeviceid\":0,\"rootdevicetype\":\"ROOT\",\"securitygroup\":[{\"id\":\"ad13aa78-bb8f-11e4-b7d5-36d1d14da5e9\",\"name\":\"default\",\"description\":\"Default
Security
Group\",\"account\":\"admin\",\"ingressrule\":[],\"egressrule\":[],\"tags\":[]}],\"nic\":[{\"id\":\"1c87d7e1-f8c9-425e-809d-7edd1a30c3a6\",\"networkid\":\"abe603fe-1d8b-4b23-9aa2-0234f18de686\",\"networkname\":\"vlan106\",\"netmask\":\"255.255.255.0\",\"gateway\":\"10.0.106.1\",\"ipaddress\":\"10.0.106.170\",\"isolationuri\":\"vlan://106\",\"broadcasturi\":\"vlan://106\",\"traffictype\":\"Guest\",\"type\":\"Shared\",\"isdefault\":true,\"macaddress\":\"06:d9:2e:00:03:f6\"}],\"hypervisor\":\"XenServer\",\"instancename\":\"i-2-346-VM\",\"tags\":[],\"details\":{\"hypervisortoolsversion\":\"xenserver56\"},\"affinitygroup\":[],\"displayvm\":true,\"isdynamicallyscalable\":true,\"ostypeid\":206,\"jobid\":\"61a62e5d-61ee-41eb-b947-0f8ef5d857c3\",\"jobstatus\":0}",
"account": "ad11bb05-bb8f-11e4-b7d5-36d1d14da5e9",
"user": "ad129c91-bb8f-11e4-b7d5-36d1d14da5e9"
}
There are two problems for above example:
1. The nested data structures are not parsed properly. As you can see, values
for both “cmdInfo” and “jobResult” are strings instead of nested hash. I have
to make additional calls to JSON parser on those values to parse them.
2. The string
"org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/“ at the
beginning of the value for “jobResult” makes this value invalid to be parsed as
JSON object at all.
Thanks for listening.
Yiping
