thanks, the backwards compatibility thing is serious but less likely
to be completely resolved. the string encoding thing should be easy to
find.
On Tue, Jul 28, 2015 at 1:20 AM, Yiping Zhang <yzh...@marketo.com> wrote:
> Just files a Doc bug, CLOUDSTACK-8679 and a code bug CLOUDSTACK-8680.
>
> Yiping
>
> On 7/27/15, 3:29 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote:
>
>>Yiping,
>>
>>
>>good rant; You are absolutely right. Did you create a ticket (or more
>>tickets) for this?
>>
>>On Mon, Jul 27, 2015 at 11:47 PM, Yiping Zhang <yzh...@marketo.com> wrote:
>>> 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-a8b4590b36b
>>>8\\\"}\",\"cmdEventType\":\"VM.DESTROY\",\"ctxUserId\":\"2\",\"httpmethod
>>>\":\"GET\",\"_\":\"1438027779033\",\"uuid\":\"b780c229-7064-47e5-97d0-a8b
>>>4590b36b8\",\"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\",\"displaynam
>>>e\":\"yz-x1\",\"account\":\"admin\",\"domainid\":\"994ff03e-bb8f-11e4-b7d
>>>5-36d1d14da5e9\",\"domain\":\"ROOT\",\"created\":\"2015-07-27T12:01:12-05
>>>00\",\"state\":\"Destroyed\",\"haenable\":false,\"zoneid\":\"1b0b4859-7b8
>>>a-41dd-8522-4dbf24345509\",\"zonename\":\"sjlab\",\"templateid\":\"e6fa41
>>>0f-4bf0-4b3c-9982-9d60e7ffc07e\",\"templatename\":\"Base\",\"templatedisp
>>>laytext\":\"Base with 32 GB root and
>>>cloud-init\",\"passwordenabled\":false,\"serviceofferingid\":\"11a5e901-b
>>>c78-45c6-8b81-a2a9e3530164\",\"serviceofferingname\":\"1CPU@1.0Ghz@1.5GB\
>>>",\"cpunumber\":1,\"cpuspeed\":1000,\"memory\":1536,\"cpuused\":\"0.56%\"
>>>,\"networkkbsread\":0,\"networkkbswrite\":2,\"diskkbsread\":2670,\"diskkb
>>>swrite\":163,\"diskioread\":0,\"diskiowrite\":0,\"guestosid\":\"a0c75a5b-
>>>bb8f-11e4-b7d5-36d1d14da5e9\",\"rootdeviceid\":0,\"rootdevicetype\":\"ROO
>>>T\",\"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\",\"netwo
>>>rkid\":\"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\",\"in
>>>stancename\":\"i-2-346-VM\",\"tags\":[],\"details\":{\"hypervisortoolsver
>>>sion\":\"xenserver56\"},\"affinitygroup\":[],\"displayvm\":true,\"isdynam
>>>icallyscalable\":true,\"ostypeid\":206,\"jobid\":\"61a62e5d-61ee-41eb-b94
>>>7-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
>>>
>>>
>>>
>>
>>
>>
>>--
>>Daan
>
--
Daan
