Description of problem: By default, the QoS on a Disk Profile is set to "[Unlimited]". When a specific profile is configured, its not possible to remove it (read: set it back to "[Unlimited]") using the API. Version-Release number of selected component (if applicable): ovirt-engine-restapi-4.2.5.2-0.1.el7ev.noarch How reproducible: Always Steps to Reproduce: 1. Under Compute -> Data Center -> Default -> QoS create a "Storage" QoS with some limits 2. Use the API to set the QoS to an existing Disk Profile # curl -k --header 'Accept: application/xml' --request 'PUT' --header 'Content-Type: application/xml' --data ' <disk_profile> <qos id="<qosuuid>"/> </disk_profile> ' -u 'admin@internal' \ 'https://rhvm.example.com/ovirt-engine/api/diskprofiles/<diskprofileuuid>' 3. Try removing it with: # curl -k --header 'Accept: application/xml' --request 'PUT' --header 'Content-Type: application/xml' --data ' <disk_profile> <qos/> </disk_profile> ' -u 'admin@internal' \ 'https://rhvm.example.com/ovirt-engine/api/diskprofiles/<diskprofileuuid>' Actual results: Reading back the same Disk Profile still contains an ID for the QoS: # curl -k --header 'Accept: application/xml' --request 'GET' -u 'admin@internal' \ 'https://rhvm.example.com/ovirt-engine/api/diskprofiles' ... <disk_profile href="/ovirt-engine/api/diskprofiles/31311c34-911d-4cfe-ba84-75b0ede0d118" id="31311c34-911d-4cfe-ba84-75b0ede0d118"> <name>Data1</name> <link href="/ovirt-engine/api/diskprofiles/31311c34-911d-4cfe-ba84-75b0ede0d118/permissions" rel="permissions"/> <qos href="/ovirt-engine/api/datacenters/1d9f9f52-a611-11e8-b40b-00163e4663ae/qoss/1b8c9ecb-ed09-44d2-8d78-280bbf20995c" id="1b8c9ecb-ed09-44d2-8d78-280bbf20995c"/> <storage_domain href="/ovirt-engine/api/storagedomains/e345a3da-805e-4206-8f91-41e309bce10b" id="e345a3da-805e-4206-8f91-41e309bce10b"/> </disk_profile> ... Expected results: The QoS to be empty. Additional info: In the webUI it is possible to set it back to "[Unlimited]". Step 3 in the reproducer does not return an error. Sending this: <disk_profile> <qos id=””/> </disk_profile> or similar calls results in a syntax error.
Martin, I recall there was a way to do it, is the syntax of the request correct though?
Ryan, do you have any idea here?
I'd expect this to be, basically: DELETE https://rhvm.example.com/ovirt-engine/api/diskprofiles/<diskprofileuuid>/qos But I'll test
Any news Ryan?
After testing, there doesn't actually seem to be a way to unset this -- DELETE throws an exception which is logged but not sent back (same as trying to delete the entire disk profile). Unsetting <data_center /> under the QOS itself also doesn't seem to work. Short of deleting the QOS entirely, I can't find another way to do this. curl -k --header 'Accept: application/xml' --request 'DELETE' -u 'admin@internal' https://engine-root.ovirt.org/ovirt-engine/api/datacenters/123/qoss/123 The REST API mapper for DiskProfile needs to provide a way to unset this.
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
I've pushed a patch to fix this to Gerrit - the empty tag <qos /> now removes the qos. However, I am wondering if this could break some existing scripts. WDYT?
It's a holiday in the US, so I won't get a chance to look until tomorrow, but thoughts on this change for Ansible, Martin?
It doesn't break Ansible or old scripts. The patch looks OK.
sync2jira
Verified on engine-4.4.0-0.13.master.el7.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: Red Hat Virtualization security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3807