ACS 4.18 diskofferingid missing from deployVirtualMachine response

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>

@harikrishna-patnala

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

server: fix diskoffering details in vm response

@shwstppr

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?

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.

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

@wido

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.

@wido

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.

@wido

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?

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.

server: fix diskoffering details in vm response (#8135)

Fixed with #8135

server: fix diskoffering details in vm response (apache#8135)

Navigation Menu

Repository navigation

ACS 4.18 diskofferingid missing from deployVirtualMachine response #8120

ISSUE TYPE

COMPONENT NAME

CLOUDSTACK VERSION

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

STEPS TO REPRODUCE

EXPECTED RESULTS

ACTUAL RESULTS

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ACS 4.18 diskofferingid missing from deployVirtualMachine response #8120

Description

ISSUE TYPE

COMPONENT NAME

CLOUDSTACK VERSION

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

STEPS TO REPRODUCE

EXPECTED RESULTS

ACTUAL RESULTS

Activity

weizhouapache commented on Oct 19, 2023

DaanHoogland commented on Nov 15, 2023

MartinEmrich commented on Nov 15, 2023

DaanHoogland commented on Nov 15, 2023

DaanHoogland commented on Nov 15, 2023

weizhouapache commented on Nov 15, 2023

shwstppr commented on Nov 16, 2023

weizhouapache commented on Nov 16, 2023

shwstppr commented on Dec 9, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions