You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Yiping Zhang <yz...@marketo.com> on 2015/07/27 23:47:20 UTC
Using cloudstack RabbitMQ events
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
Re: Using cloudstack RabbitMQ events
Posted by Daan Hoogland <da...@gmail.com>.
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 <yz...@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" <da...@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 <yz...@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
Re: Using cloudstack RabbitMQ events
Posted by Yiping Zhang <yz...@marketo.com>.
Just files a Doc bug, CLOUDSTACK-8679 and a code bug CLOUDSTACK-8680.
Yiping
On 7/27/15, 3:29 PM, "Daan Hoogland" <da...@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 <yz...@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
Re: Using cloudstack RabbitMQ events
Posted by Daan Hoogland <da...@gmail.com>.
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 <yz...@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-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
>
>
>
--
Daan