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\":\"1CPU@1.0Ghz@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



Reply via email to