Cause:
Amend a VM disk attachment without any QCOW volumes is allowed and show a success response through REST.
Consequence:
The amend operation go through every volume in the disk and filter out all the QCOW volumes to amend.
Since there are no any, the operation will be finished with success.
Fix:
Introduce a new validation with reasonable error which will be presented to the user once a VM disk attachment without any QCOW volumes will be amended.
Result:
A validation message will be presented to the user once the QCOW version is changed for a disk without any QCOW volumes.
A user might still see a successful response through REST even if no change has been done on the disk, this is the current behavior through REST (For example when a disk alias/description is being updated with the same value as before or if disk is being amended with the same QCOW version as before).
Created attachment 1277391[details]
engine & vdsm logs
Description of problem:
Amend (update VM disk attachment disk qcow2_v3 field) to raw disk is allowed.
Version-Release number of selected component (if applicable):
Engine:
4.1.2.1
How reproducible:
100%
Steps to Reproduce:
1.Create VM with RAW disk
2.Via RESTAPI amend disk
Actual results:
The response is successful & event log shows an update is successful.
Event log:
May 9, 2017, 4:54:49 PM
VM vm_TestCase18349_REST_NFS_0916144083 vm_TestCase18349_REST_NFS_0916144083_Disk1 disk was updated by admin@internal-authz.
Expected results:
I would expect that update qcow2_v3 to VM disk attachment on a RAW disk that does not have this field will fail with a reasonable error.
Additional info:
RESTAPI amend request:
URL:
https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/vms/cee54bba-c327-4e34-9482-6d77781d8627/diskattachments/dd39bbc5-fd3d-4c7b-ba3f-6e9c640ead22
Body:
<disk_attachment>
<disk>
<qcow_version>qcow2_v3</qcow_version>
</disk>
</disk_attachment>
The following validation message will be presented to the user once the QCOW version is changed for a disk without any QCOW volumes:
"Cannot ${action} ${type}. The amend operation does not support disk without any QCOW2 volumes."
A user might still see a successful response through REST even if no change has been done on the disk, this is the current behavior through REST (For example update the disk alias/description with the same value or amend a disk to the same QCOW version)
As mentioned in comment 2
patch https://gerrit.ovirt.org/77308 was not part of ovirt-engine-4.1.3 tag, therefore it should not be moved to ON_QA for target 4.1.3, moving again to modified until next build of 4.1.4.
(In reply to Maor from comment #3)
> As mentioned in comment 2
> patch https://gerrit.ovirt.org/77308 was not part of ovirt-engine-4.1.3 tag,
> therefore it should not be moved to ON_QA for target 4.1.3, moving again to
> modified until next build of 4.1.4.
It's part of the ovirt-engine-4.1.3.1 resping. Moving back to 4.1.3 and setting ON_QA.