[
https://issues.apache.org/jira/browse/CLOUDSTACK-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584471#comment-13584471
]
Min Chen commented on CLOUDSTACK-1357:
--------------------------------------
Are you saying that in 4.0, ListUserVmCmd does not have jobStatus packed? This
seems not true based on my understanding of the code below in 4.0 branch
ApiServer.java:
// if the command is of the listXXXCommand, we will need to also
return the
// the job id and status if possible
if (cmdObj instanceof BaseListCmd) {
buildAsyncListResponse((BaseListCmd) cmdObj, caller);
}
As you can see, for listXXXCommand, we will always go to AsyncJob table to find
if there is pending job for the instance Id, and then fill jobId and jobStatus
in UserVmResponse. BTW, jobId and jobStatus are fields in BaseResponse from
4.0, not newly added for 4.1. I can understand that for deployVmCmd, in 4.0,
the returned UserVmResponse may not have jobId and jobStatus set. In 4.1, due
to API refactoring, we are using newly created DB views to uniformly generate
UserVmResponse, so for deployVmCmd we will also set jobId and jobStatus in
returned UserVmResponse. To me, functionality-wise this is not wrong, actually
gives us a consistent UserVmResponse for every command instead of manually
distinguishing listXXXcmd or non-listXXXCmd. From what you are sayiing, the
only impact is that the client who invokes queryAsyncJobResult needs to use
more accurate XPath to access the jobStatus for the async job you are querying,
but I think that it is reasonable, and should not be a big change. But I agree
that we may need to document this change.
> Duplicate <jobstatus> inside DeployVM's job response virtualmachine object
> Was: (Autoscale: Provisioned VMs from Netscaler not being added to lb
> vserver, provserver fails with provserver_err_asynctaskpoll)
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-1357
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1357
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
> Affects Versions: 4.1.0
> Environment: Ubuntu 11.10, XS 6.1, Netscaler v 10.0
> Reporter: Sowmya Krishnan
> Assignee: Vijay Venkatachalam
> Priority: Blocker
> Fix For: 4.1.0
>
> Attachments: nslog
>
>
> VMs are getting provisioned but are not getting added to the lb vserver. DNS
> records not created either. Following is the provision log from ns.log:
> Feb 21 07:02:29 <local0.notice> ns provserverd[393]: Job provision request
> for Service Group (Cloudabc622303efb4ebe9ad4fa272103e2fd)
> Feb 21 07:02:34 <local0.info> 10.102.192.50 02/21/2013:07:02:34 GMT 0-PPE-0
> : UI CMD_EXECUTED 3108 0 : User nsroot - Remote_ip 10.144.7.15 - Command
> "show lb vserver Cloud-VirtualServer-1
> 0.102.196.245-22" - Status "Success"
> Feb 21 07:02:59 <local0.warn> ns provserverd[393]: Job with job type (0) for
> Service Group (Cloudabc622303efb4ebe9ad4fa272103e2fd) -> Error :
> provserver_err_asynctaskpoll
> Feb 21 07:03:29 <local0.notice> ns provserverd[393]: Job provision request
> for Service Group (Cloudabc622303efb4ebe9ad4fa272103e2fd)
> Steps
> =====
> 1. Create an Autoscale config with suitable template and min members as 2 and
> max as 5. Set appropriate scale up and scale down policies
> 2. Verify lb rule is created in Netscaler
> Result
> =====
> Status of lb vserver is DOWN and dns record is not added for the deployed VM.
> VMs continue to get deployed but it is not getting added to the lb vserver
> Expected Result
> =============
> 2 VMs should be provisioned and added to lb vserver and dns records for the
> VMs should get added as well.
> lb vserver status should be UP and so should the services.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
