[
https://issues.apache.org/jira/browse/CLOUDSTACK-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641928#comment-13641928
]
Min Chen commented on CLOUDSTACK-2126:
--------------------------------------
This is introduced by API performance refactoring, the intent is to generate
the same response object for both listxxx api and other apis related to the
same entity. I disagree the above statement "Ideally response should stick to
what is exposed by the docs and the associated response class: In the case of
DeployVM there is no response attribute for jobstatus. jobstatus attribute
makes no sense for virtualmachine." Current behavior is not violating this. If
you look at deployVMCmd, its response object is UserVmResponse, which is
inherited from BaseResponse. In BaseResponse, we always have jobId and
jobStatus fields. so I don't understand why this will cause json
deserialization issue? Just like istVMsCmd, which always return associated
async job id and job status for this UserVm (this is the behavior in 4.0), I
don't see any issues in returning this information in deployVMCmd to get the
consistent UserVmResponse content in both listVMsCmd and deployVMCmd.
> Response objects of some entities contain job related information
> -----------------------------------------------------------------
>
> Key: CLOUDSTACK-2126
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2126
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
> Affects Versions: 4.1.0, 4.2.0
> Reporter: Prasanna Santhanam
> Priority: Critical
> Fix For: 4.1.0, 4.2.0
>
>
> Response objects of various entities seem to have introduced jobstatus,
> jobid, jobuuid into their responses. These belong to the
> queryAsyncJobResponse and not the response of the entity itself:
> Eg: deployVirtualMachineResponse:
> https://gist.github.com/vogxn/5429546
> Snippet:
> {
> "queryasyncjobresultresponse": {
> "accountid": "50b6647e-a8ca-11e2-8a60-0c06fde16e85",
> "userid": "50b68bde-a8ca-11e2-8a60-0c06fde16e85",
> "cmd": "org.apache.cloudstack.api.command.user.vm.DestroyVMCmd",
> "jobstatus": 1,
> "jobprocstatus": 0,
> "jobresultcode": 0,
> "jobresulttype": "object",
> "jobresult": {
> "virtualmachine": {
> "id": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
> "name": "649663f7-3c8d-4e0d-b693-4b1ea6085a84",
> "account": "QX7KKV",
> "domainid": "50b6593e-a8ca-11e2-8a60-0c06fde16e85",
> "domain": "ROOT",
> "created": "2013-04-21T18:36:58+0530",
> "state": "Destroyed",
> "haenable": false,
> "zoneid": "6e301be1-8010-4b57-9638-c90761e40dc9",
> "zonename": "Sandbox-simulator",
> "templateid": "570c6828-a8ca-11e2-8a60-0c06fde16e85",
> "templatename": "CentOS 5.3(64-bit) no GUI (Simulator)",
> "templatedisplaytext": "CentOS 5.3(64-bit) no GUI
> (Simulator)",
> "passwordenabled": false,
> "serviceofferingid": "b1ab015a-2e8e-4f42-a6c2-f652d097fbf6",
> "serviceofferingname": "SmallServiceOffering0W2VOH",
> "cpunumber": 1,
> "cpuspeed": 100,
> "memory": 100,
> "guestosid": "5026c2c4-a8ca-11e2-8a60-0c06fde16e85",
> "rootdeviceid": 0,
> "rootdevicetype": "ROOT",
> "securitygroup": [],
> "nic": [
> {
> "id": "11517c3a-da75-4743-b4f5-2271dd919df9",
> "networkid": "7f7278dc-0352-44e6-b50d-56e59a7d19f3",
> "networkname": "QX7KKV-network",
> "netmask": "255.255.255.0",
> "gateway": "10.1.1.1",
> "ipaddress": "10.1.1.2",
> "traffictype": "Guest",
> "type": "Isolated",
> "isdefault": true,
> "macaddress": "02:00:3e:2e:00:01"
> }
> ],
> "hypervisor": "Simulator",
> "instancename": "i-232-35-QA",
> "tags": [],
> "affinitygroup": [],
> "jobstatus": 0 ####INVALID ENTRY INSIDE VIRTUALMACHINE####
> }
> },
> "created": "2013-04-21T18:37:04+0530",
> "jobid": "340120e2-632b-4a03-b416-21c23b4e95d1"
> }
> }
> This seems to have come through during the api refactoring. Ideally response
> should stick to what is exposed by the docs and the associated response
> class: In the case of DeployVM there is no response attribute for jobstatus.
> jobstatus attribute makes no sense for virtualmachine.
> This breaks deserializing the object into a VirtualMachine response when
> consumed by Marvin.
> Other entities that have similar issues:
> server/src/com/cloud/api/query/dao/AccountJoinDaoImpl.java:
> accountResponse.setJobStatus(account.getJobStatus());
> server/src/com/cloud/api/query/dao/AsyncJobJoinDaoImpl.java:
> jobResponse.setJobStatus(job.getStatus());
> server/src/com/cloud/api/query/dao/DomainRouterJoinDaoImpl.java:
> routerResponse.setJobStatus(router.getJobStatus());
> server/src/com/cloud/api/query/dao/HostJoinDaoImpl.java:
> hostResponse.setJobStatus(host.getJobStatus());
> server/src/com/cloud/api/query/dao/HostJoinDaoImpl.java:
> hostResponse.setJobStatus(host.getJobStatus());
> server/src/com/cloud/api/query/dao/SecurityGroupJoinDaoImpl.java:
> sgResponse.setJobStatus(vsg.getJobStatus());
> server/src/com/cloud/api/query/dao/StoragePoolJoinDaoImpl.java:
> poolResponse.setJobStatus(pool.getJobStatus());
> server/src/com/cloud/api/query/dao/StoragePoolJoinDaoImpl.java:
> poolResponse.setJobStatus(pool.getJobStatus());
> server/src/com/cloud/api/query/dao/UserAccountJoinDaoImpl.java:
> userResponse.setJobStatus(usr.getJobStatus());
> server/src/com/cloud/api/query/dao/UserVmJoinDaoImpl.java:
> userVmResponse.setJobStatus(userVm.getJobStatus());
> server/src/com/cloud/api/query/dao/VolumeJoinDaoImpl.java:
> volResponse.setJobStatus(volume.getJobStatus());
> server/src/com/cloud/api/query/vo/AccountJoinVO.java: public void
> setJobStatus(int jobStatus) {
> server/src/com/cloud/api/query/vo/DomainRouterJoinVO.java: public void
> setJobStatus(int jobStatus) {
> server/src/com/cloud/api/query/vo/HostJoinVO.java: public void
> setJobStatus(int jobStatus) {
> server/src/com/cloud/api/query/vo/SecurityGroupJoinVO.java: public void
> setJobStatus(int jobStatus) {
> server/src/com/cloud/api/query/vo/StoragePoolJoinVO.java: public void
> setJobStatus(int jobStatus) {
> server/src/com/cloud/api/query/vo/UserAccountJoinVO.java: public void
> setJobStatus(int jobStatus) {
> server/src/com/cloud/api/query/vo/UserVmJoinVO.java: public void
> setJobStatus(int jobStatus) {
> server/src/com/cloud/api/query/vo/VolumeJoinVO.java: public void
> setJobStatus(int jobStatus) {
> The associated views contain the response as well which is where they seem to
> be coming from:
> | job_id | bigint(20) unsigned | YES | | 0 | |
> | job_uuid | varchar(40) | YES | | NULL | |
> | job_status | int(1) | YES | | NULL | |
> | job_account_id | bigint(20) unsigned | YES | | NULL | |
> +-----------------------+---------------------+------+-----+---------+-------+
--
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
