On Thu, Apr 25, 2013 at 09:30:08AM -0700, Min Chen wrote:
> Prasanna, I updated CLOUDSTACK-2126 with my comment. That is the intended
> change done in list API performance improvement work, and I don't see any
> issues by having the consistent UserVmResponse for both deployVMCmd and
> listVMsCmd. Every BaseResponse class has jobId and jobStatus as serialized
> fields, I don't see why marvin has issues in deserialization in this case.
> Did I miss anything?
>
I'm not sure why internal representation should be a reason to surface
it upwards. But that's not the part I'm concerned with: If you look at
the response carefully - queryAsyncJobResultResponse contains two
jobstatus attributes. One for the query job and one as part of the
virtualmachine (within the virtualmachine block). The concern is with
the latter.
That block pasted for brevity:
virtualmachine : {
"id": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
"name": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
"account": "QX7KKV",
...
..
"zoneid": "6e301be1-8010-4b57-9638-c90761e40dc9",
"jobstatus": 0 <?My Problem?>
}
These attributes qualify a VM, but I'm not sure why jobstatus is in
there. That's an attribute of the job itself which is CloudStack's
concern, but not the VM's concern. When marvin looks to deserialize
back to a VM object, it looks at the inner block only. I can
workaround these within marvin, so feel free to reduce the priority if
you think the bug can be fixed later. Just that jobstatus represented
as a VM attribute doesn't seem right to me.
Thanks,
--
Prasanna.,
------------------------
Powered by BigRock.com
