Description of problem: Currently when trying to add a disk to a VM using the RESTAPI the caller is forced to specify a disk profile if the storage domain has more than one disk profile specified. Version-Release number of selected component (if applicable): ovirt-engine-3.5.0.1-1.el6.noarch How reproducible: Always. Steps to Reproduce: 1. Create a storage domain with more than one disk profile, and a VM. 2. Try to add a disk to the VM using the RESTAPI, but without specifying the <disk_profile id="..."/> element: #!/bin/sh -ex url="https://ovirt.example.com/ovirt-engine/api"; user="admin@internal" password="******" curl \ --verbose \ --insecure \ --request POST \ --user "${user}:${password}" \ --header "Content-Type: application/xml" \ --header "Accept: application/xml" \ --data ' <disk> <storage_domains> <storage_domain id="00f5dfb8-9068-40c7-99c5-196c67e3ca99"/> </storage_domains> <size>1</size> <type>data</type> <bootable>false</bootable> <interface>virtio</interface> <format>cow</format> <sparse>true</sparse> </disk> ' \ "${url}/vms/7690010b-d3b8-4ad3-8bcd-4a2cc54fc571/disks" Actual results: The operation fails with the following result: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault> <reason>Operation Failed</reason> <detail>[action type disk profile empty]</detail> </fault> Expected results: The operation should succeed and automatically select one of the available disk proviles, otherwise existing callers will start failing the moment a new profile is added to the storage domain.
Isn't this a regression from 3.4 ? Afaik if no profile is specified the "default" profile should be used. As this is a regression this should imho block 3.5.1 release.
Yes, it is a regression.
(In reply to Juan Hernández from comment #2) > Yes, it is a regression. 1st the disk profiles are not exposed to rest. this should be fixed 2nd well that's a new feature and I don't assume a user would like us to pick a profile for him. user would still have to choose.
Disks profiles are exposed, in the top level "diskprofiles" collection. Callers that are not aware of this feature shouldn't fail. We do need to pick a profile automatically for them, otherwise we are breaking backwards compatibility. The backend should designate one of the disk profiles as the "default" and use it automatically when no one has been explicitly specified by the caller. This default can just be the first profile added, or you may want to add support to the RESTAPI so that the caller may (in a separate call) specify what is the default disk profile (for a data center or storage domain). Whatever we do a request to create a disk that used to work can't suddenly stop working.
This is an automated message: This bug should be fixed in oVirt 3.5.1 RC1, moving to QA
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.
this ovirt bug was fixed during 3.5.1 cycle and is included in the build, and therefore should be verified.
*** Bug 1196972 has been marked as a duplicate of this bug. ***
ok, rhevm-backend-3.5.1-0.1.el6ev.noarch > [...] This default can just be the first profile added [...] works as described
This is an automated message. oVirt 3.5.4 has been released on September 3rd 2015 and should include the fix for this BZ. Moving to closed current release.