Description of problem: Trying to update a disk attribute via API does not work. # curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:redhat' \ --request PUT \ --header 'Version: 4' \ --header 'Content-Type: application/xml' \ --header 'Accept: application/xml' \ --data ' <disk> <propagate_errors>true</propagate_errors> </disk> ' \ https://rhvm.rhvlab/ovirt-engine/api/disks/4d380f88-9f64-4267-bdae-2ebeb5920eaf No error is returned, but the attribute is still set to the old value. All other attributes seem to have the same behavior. Also, if going via diskattachments, then it works. But some properties are by disk (i.e. propagate_errors) so it makes more sense to PUT to disks instead of diskattachments. Version-Release number of selected component (if applicable): ovirt-engine-4.2.6.4-1.el7.noarch ovirt-engine-restapi-4.2.6.4-1.el7.noarch How reproducible: 100% Steps to Reproduce: As above Actual results: Disk attribute not updated Expected results: Disk attribute updated
Allowing update in diskattachment context and not in disk context was a design decision, see discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=1429437 I actually agree with Juan's comment #6 in the discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1429437#c6 but he gave the final say to the storage team and that's how it stayed There is one exception by the way, qcow2, which is updated at the disk level, see: https://gerrit.ovirt.org/#/c/67849/ In my opinion the approach of managing general disk properties should be done at the disk level, and managing properties of the relationship VM<-->Disk should be done at the disk-attachemnt level, as Juan said. So I agree that this is a bug but I would like to hear the input of Storage team
Yes, this was a design decision, same as in the Webadmin in which you cannot edit a disk via the disks main tab but only through the disks sub tab of a VM. Disk properties are editable from within /vms/{vm_id}/diskattachments/{disk_attachment_id}
(In reply to Tal Nisan from comment #2) > Yes, this was a design decision, same as in the Webadmin in which you cannot > edit a disk via the disks main tab but only through the disks sub tab of a > VM. > Disk properties are editable from within > /vms/{vm_id}/diskattachments/{disk_attachment_id} Hi Tal, Its fine if this is a design decision. But could we change this to a RFE to at least make the engine return an error/message instead of OK? Accepting the PUT, returning OK and doing nothing is not user friendly. Makes people waste time debugging and eventually raise more bugs like this one.
Returning an error message (not allowed maybe?) makes perfect sense to me, Ondra what do you think?
Sorry missed the needinfo. Yes it makes sense to return an error. I would use HTTP 409.
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.
all referenced patches are merged, can you please check this bug status? Should it be in modified?
Verified on ovirt-engine-4.3.2.1-0.1.el7.noarch. Engine now returns error: <fault> <detail>Updating disk attributes other than QCOW version is permitted only for disk-attachments, which reside under VMs.</detail> <reason>Operation Failed</reason> </fault>
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, 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/RHEA-2019:1085
sync2jira
I have been unable to use this to update a disk quota. The quota attribute is located in /disks, not /disk_attachments. Example: curl -v -u "user@server:password" -H "Content-type: application/xml" -data "<disk_attachment><quota id='ccc'/></disk_attachment>" 'https://blowfish/ovirt-engine/api/vms/xxx/diskattachments/bbb' This returns invalid while attempting to update the disk directly returns the error message: "<fault> <detail>Updating disk attributes other than QCOW version is permitted only for disk-attachments, which reside under VMs.</detail> <reason>Operation Failed</reason> </fault>" Is disk quota updating via the API no longer supported?