In 4.0, CS has special code to return job status for a VM returned from
listVMsCmd. During API performance refactoring, I have a created a DB view
user_vm_view that joins async_job table just for that purpose and used
that view to uniformly generate UserVmResponse. So the same code will be
applied to generate UserVmResponse whenever it is used. In this case,
deployVMCmd itself will also return a UserVmResponse, thus the same code
applied, and so that is what you see. If we all agree that job status
should not appear in UserVmResponse, then I can change the view to remove
job from async_job. But I would argue that we should not return jobStatus
in ListVmsCmd as well, this will also be a change from 4.0 release.
Thanks
-min
On 4/25/13 9:48 AM, "Prasanna Santhanam" <t...@apache.org> wrote:
>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
>
