Bug 1643520
| Summary: | RESTAPI Not able to remove the QoS from a disk profile | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ron van der Wees <rvdwees> |
| Component: | ovirt-engine | Assignee: | Lucia Jelinkova <ljelinko> |
| Status: | CLOSED ERRATA | QA Contact: | Evelina Shames <eshames> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.2.5 | CC: | ahadas, frolland, michal.skrivanek, mperina, msivak, mtessun, omachace, sgoodman, tnisan |
| Target Milestone: | ovirt-4.4.1 | Flags: | lsvaty:
testing_plan_complete-
|
| Target Release: | 4.3.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Before this update, when updating a disk profile using the REST API, sending an empty QoS tag `<qos />` had no effect. Consequently, it was not possible to remove QoS from the disk profile using the REST API.
This update resolves this issue, and now sending an empty QoS tag (`<qos />`) removes QoS from the disk profile.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-09-23 16:11:04 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 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 |
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.