JobId/JobStatus were introduced to the list* responses on purpose. Some of
the CS customers wanted to see what async jobs that are currently being
executed on the object, just by looking at the result of list* command.
So removing async job params from the list response is not a good idea as
customers' software might rely on its presence.
On 4/25/13 10:32 AM, "Min Chen" <min.c...@citrix.com> wrote:
>Totally agree.
>
>Chip and others, Prasanna and I exchanged ideas about CLOUDSTACK--2126,
>and we both agree that we should only return async job Id and job status
>in queryAsyncJob and listAsyncJob commands, not in any other APIs so that
>we can have consistent response return in various scenarios. If we fix
>this way, the behavior for listXXX api is changed. In 4.0, CloudStack has
>used ApiServer.buildAsyncListResponse() routine to fill in async job Id
>and status for all listXXX Apis. With the proposed fix, we will not show
>async job information in listXXX response as well. Not sure if anybody see
>any side effect on this slight change from 4.0? Anybody know the reason
>why we had that special code in 4.0 to return async job for listXXX api?
>Since the proposed change will affect all newly created db view in 4.1, we
>suggest that this can be fixed in 4.2 since current behavior is not
>breaking functionalities, just return more information. Any thoughts?
>
>Thanks
>-min
>
>
>
>
>
>
>On 4/25/13 10:05 AM, "Prasanna Santhanam" <t...@apache.org> wrote:
>
>>That's odd - listXxx commands don't do async at all and shouldn't be
>>generating jobstatus,jobid etc. So I'm not sure why that was added in
>>(prior?) 4.0. I'd like to take that out too if there's no real reason
>>behind it.
>>
>>--
>>Prasanna.,
>>
>>On Thu, Apr 25, 2013 at 09:57:02AM -0700, Min Chen wrote:
>>> 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
>>> >
>>
>>
>>------------------------
>>Powered by BigRock.com
>>
>
>
