ACS 4.18 diskofferingid missing from deployVirtualMachine response

[MartinEmrich]

ISSUE TYPE

• Bug Report

COMPONENT NAME

API

CLOUDSTACK VERSION

4.18

CONFIGURATION

Hypervisor: XenServer

OS / ENVIRONMENT

CentOS 7

SUMMARY

In ACS up until 4.11.2.0, the response to the deployVirtualMachine API call contained the data disk diskofferingid and diskofferingname

I noticed that on ACS 4.18, this is no longer the case.

STEPS TO REPRODUCE

deploy a virtual machine with disk offering and size set.

API call extracted from ACS log file:

2023-10-19 09:41:56,493 DEBUG [c.c.a.ApiServlet] (qtp1444635922-841947:ctx-fcdbc879) (logid:08db5be6) ===START===  10.12.0.248 -- GET  details%5B0%5D.cpuNumber=2&serviceOfferingId=8b6add88-0261-4d05-b04b-146032b8f35b&networkids=6710de0c-d4f5-48bf-bd8b-1543c4d3f888&size=20&details%5B0%5D.cpuSpeed=1000&displayname=test-deb-4%20test-deb-4&name=test-deb-4&zoneId=e99e796c-4e5c-4549-a0d7-ddd3d8526c06&templateId=e9606f2c-a1d1-4548-ae52-00dc36e17662&command=deployVirtualMachine&details%5B0%5D.memory=2048&diskofferingid=05255aa1-1ef4-4698-a151-67809848a646&apiKey=xxxx&signature=xxxx

EXPECTED RESULTS

My application polls the job result, and also depends on the returned diskofferingid and diskofferingname fields in the resulting XML document. But both fields are missing, making the application think there is no data disk.

Before the upgrade to ACS 4.18, this did work. The API docs still list both fields for the response: https://cloudstack.apache.org/api/apidocs-4.18/apis/deployVirtualMachine.html

ACTUAL RESULTS

The fields are missing now. Result of the job:

<?xml version="1.0" encoding="UTF-8"?>
<queryasyncjobresultresponse cloud-stack-version="4.18.1.0-SNAPSHOT">
    <accountid>813308c2-8405-46c3-aa09-0e6bbd90e3b1</accountid>
    <userid>5f52698d-cdd1-4ce2-ad15-128e414eb42d</userid>
    <cmd>org.apache.cloudstack.api.command.user.vm.DeployVMCmd</cmd>
    <jobstatus>1</jobstatus>
    <jobprocstatus>0</jobprocstatus>
    <jobresultcode>0</jobresultcode>
    <jobresulttype>object</jobresulttype>
    <jobresult>
        <virtualmachine>
            <id>c4563c04-4e2f-43df-874f-44b90c6627a4</id>
            <name>test-deb-4</name>
            <displayname>test-deb-4 test-deb-4</displayname>
            <account>admin</account>
            <userid>5f52698d-cdd1-4ce2-ad15-128e414eb42d</userid>
            <username>admin</username>
            <domainid>f8082002-79f2-41f8-affe-7b8328a8dd20</domainid>
            <domain>XX</domain>
            <created>2023-10-19T09:41:56+0200</created>
            <lastupdated>2023-10-19T09:42:33+0200</lastupdated>
            <state>Running</state>
            <haenable>true</haenable>
            <zoneid>e99e796c-4e5c-4549-a0d7-ddd3d8526c06</zoneid>
            <zonename>XXX</zonename>
            <hostcontrolstate>Enabled</hostcontrolstate>
            <templateid>e9606f2c-a1d1-4548-ae52-00dc36e17662</templateid>
            <templatename>debian-12</templatename>
            <templatedisplaytext>Debian 12.2 20231018</templatedisplaytext>
            <passwordenabled>false</passwordenabled>
            <serviceofferingid>8b6add88-0261-4d05-b04b-146032b8f35b</serviceofferingid>
            <serviceofferingname>xxx</serviceofferingname>
            <cpunumber>2</cpunumber>
            <cpuspeed>1000</cpuspeed>
            <memory>2048</memory>
            <guestosid>9a37c197-7197-4eee-93ef-e428560d4244</guestosid>
            <rootdeviceid>0</rootdeviceid>
            <rootdevicetype>ROOT</rootdevicetype>
            <nic>
                <id>903ff7fa-c03d-4277-b6e6-c86216090921</id>
                <networkid>6710de0c-d4f5-48bf-bd8b-1543c4d3f888</networkid>
                <networkname>xxx</networkname>
                <netmask>xxx</netmask>
                <gateway>xxx</gateway>
                <ipaddress>xxx</ipaddress>
                <isolationuri>xxx</isolationuri>
                <broadcasturi>xxx</broadcasturi>
                <traffictype>Guest</traffictype>
                <type>Shared</type>
                <isdefault>true</isdefault>
                <macaddress>xxx</macaddress>
                <deviceid>0</deviceid>
            </nic>
            <hypervisor>XenServer</hypervisor>
            <details>
                {cpuNumber=2, memory=2048, cpuSpeed=1000, hypervisortoolsversion=xenserver56,
                platform=device-model:qemu-upstream-compat;apic:true;viridian:true;timeoffset:0;pae:true;acpi:1;hpet:true;secureboot:false;nx:true}</details>
            <readonlydetails>dataDiskController, rootDiskController</readonlydetails>
            <isdynamicallyscalable>true</isdynamicallyscalable>
            <ostypeid>9a37c197-7197-4eee-93ef-e428560d4244</ostypeid>
            <osdisplayname>Debian GNU/Linux 12 (64-bit)</osdisplayname>
            <pooltype>PreSetup</pooltype>
            <receivedbytes>0</receivedbytes>
            <sentbytes>0</sentbytes>
            <hasannotations>false</hasannotations>
            <jobid>abbf6274-ccd1-437d-912a-d94999e8771c</jobid>
            <jobstatus>0</jobstatus>
        </virtualmachine>
    </jobresult>
    <jobinstancetype>VirtualMachine</jobinstancetype>
    <jobinstanceid>c4563c04-4e2f-43df-874f-44b90c6627a4</jobinstanceid>
    <created>2023-10-19T09:41:56+0200</created>
    <completed>2023-10-19T09:42:33+0200</completed>
    <jobid>abbf6274-ccd1-437d-912a-d94999e8771c</jobid>
</queryasyncjobresultresponse>

[weizhouapache]

I am able to reproduce the issue. the disk offering information is not displayed in the response of listVirtualMachines api either.

this seems be caused by #5008 cc @harikrishna-patnala @shwstppr

[DaanHoogland]

there is another issue with this response in my view @shwstppr @MartinEmrich @weizhouapache ; it contains a nic, while the VM might have more then one the same is true for the disk(offering)s

Do you think it is worth it to creep that into the scope here?

[MartinEmrich]

I guess I don't have a strong opinion on that. In the meantime, I changed my application to no longer rely on the diskoffering fields, so I'll take whatever happens. But if one can deployVirtualMachine with multiple disks and/or NICs, I would expect tem to be listed in their order in the result.

[DaanHoogland]

But if one can deployVirtualMachine with multiple disks and/or NICs, I would expect tem to be listed in their order in the result.

agreed

[DaanHoogland]

Come to think of it; this will have performance repercussions when listing a lot of VMs. We might want to make it optional or add a flag or setting tho enable/disable the behaviour of retrieving all dependent information with the VM. @wido @weizhouapache @rohityadavcloud @shwstppr @harikrishna-patnala @GutoVeronezi @mlsorensen , any input on this matter? Keep in mind this is a regression as well.

[weizhouapache]

Come to think of it; this will have performance repercussions when listing a lot of VMs. We might want to make it optional or add a flag or setting tho enable/disable the behaviour of retrieving all dependent information with the VM. @wido @weizhouapache @rohityadavcloud @shwstppr @harikrishna-patnala @GutoVeronezi @mlsorensen , any input on this matter? Keep in mind this is a regression as well.

@DaanHoogland there is a vmdetail option named volume

    public enum VMDetails {
        all, group, nics, stats, secgrp, tmpl, servoff, diskoff, backoff, iso, volume, min, affgrp;
    }

if details is all or contains volume, it should be better to return more information of volumes. currently only rootdeviceid and rootdevicetype are displayed, which is useless.

[shwstppr]

Come to think of it; this will have performance repercussions when listing a lot of VMs. We might want to make it optional or add a flag or setting tho enable/disable the behaviour of retrieving all dependent information with the VM. @wido @weizhouapache @rohityadavcloud @shwstppr @harikrishna-patnala @GutoVeronezi @mlsorensen , any input on this matter? Keep in mind this is a regression as well.

The problem is probably only with volumes. I checked nic already returns an array of VM nics

I like the idea of using details param to list VMs with details of their volumes. Any way we should update the description for diskofferingid and diskofferingname params or restore the behaviour as it was before 4.16?

[weizhouapache]

The problem is probably only with volumes. I checked nic already returns an array of VM nics

I like the idea of using details param to list VMs with details of their volumes. Any way we should update the description for diskofferingid and diskofferingname params or restore the behaviour as it was before 4.16?

I think we could mark diskofferingid and diskofferingname as deprecated and do not set the values, as they do not consider if there are multiple data disks.

[shwstppr]

Fixed with #8135