Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1429437

Summary: REST API - qcow version does not update via path: / ovirt-engine/api/vms/<VM-ID>/diskattachments/<disk-attachment-id>/
Product: [oVirt] ovirt-engine Reporter: Avihai <aefrat>
Component: RestAPIAssignee: Maor <mlipchuk>
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Stehlik <pstehlik>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.1.1.2CC: bugs, juan.hernandez, ratamir, tnisan
Target Milestone: ovirt-4.1.1-1Flags: rule-engine: ovirt-4.1+
Target Release: 4.1.1.6   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: amend of qcow volume should be supported only from 'vms/{vm:id}/diskattachments/{attachment:id}' endpoint Consequence: The amend was only supported via the 'disks/{disk:id}' endpoint. This endpoint is vat valid yet to use by customers. Fix: Support amend of qcow volume from 'vms/{vm:id}/diskattachments/{attachment:id}' endpoint. Result: amend of qcow volume is supported from 'vms/{vm:id}/diskattachments/{attachment:id}' endpoint the 'disks/{disk:id}' endpoint has been decommissioned
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-21 09:45:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
engine & vdsm logs none

Description Avihai 2017-03-06 11:35:00 UTC
Created attachment 1260368 [details]
engine & vdsm logs

Description of problem:
qcow version does not update (amend does not start) using PUT via RESTAPI PUT via path:
/ovirt-engine/api/vms/<VM-ID>/diskattachments/<disk-attachment-id>/


Version-Release number of selected component (if applicable):
Engine - 4.1.1.2-0.1.el7
VDSM   - 4.19.6-1

How reproducible:
100%


Steps to Reproduce:
1.create VM with disk
2.try to update qcow version via REST API PUT .
3.Body of the REST API:

2017-03-06 11:30:10,517 - MainThread - diskattachments - DEBUG - PUT request content is --  url:/ovirt-engine/api/vms/0ffb35b6-2002-4697-ba57-0396c523c6bc/diskattachments/9e49608e-429d-4c41-90ad-dea9be5aa3fb body:<disk_attachment>
    <disk>
        <alias>vm_TestCase18336_REST_ISCS_0610212779_Disk1</alias>
        <qcow_version>qcow2_v3</qcow_version>
    </disk>
</disk_attachment>


Actual results:
qcow version does not update , amend does not start.


Expected results:
qcow version should be updated to v3 , amend should start .

Additional info:
I try to update "wipe after delete" to same path (vms/0ffb35b6-2002-4697-ba57-0396c523c6bc/diskattachments)  and saw it does work .

But trying to update qcow_version does not work .

Comment 1 Juan Hernández 2017-03-06 11:46:54 UTC
The 'vms/{vm:id}/diskattachments/{attachment:id}' endpoint should not support any update to the disk itself, only to the disk attachment attributes. So the bug here is that 'wipe_after_delete' can be updated, that is what should be fixed.

Updates to disk attributes, like the QCOW version, should go via the 'disks/{disk:id}' endpoint.

Comment 2 Maor 2017-03-06 12:50:42 UTC
Changing the summary based on comment 1.
disk attachment should not update disk attributes, therefore wipe_after_delete should not execute

Comment 3 Maor 2017-03-06 14:32:46 UTC
I discussed the issue with Tal and Juan.
I'm setting back the summary since the engine should support certain disks' attributes update through the disk attachments REST API.

Comment 4 Raz Tamir 2017-03-06 14:51:45 UTC
FYI,
This blocks our ability to test the qCOW2v3 feature and it's part related to new HSM infrastructure.

Raise the severity to high

Comment 5 Maor 2017-03-06 15:06:03 UTC
before I post a fix,
are we sure that we want to support this update also through diskattachments.
Since this field is related to qcow header, it is not a regular attribute that we allow to update through the GUI (like other attributes such as wipe_after_delete).
This field is more resemble to volume type

Comment 6 Juan Hernández 2017-03-06 15:22:31 UTC
In my opinion no disk attribute should be updatable via the disk attachment. Only the disk attachment attributes should. For everything else, there is the disks/{disk:id} resource.

Raz, why does this block your tests? Can't you find the disk id and then go to disks/{disk:id} to do the update?

Comment 7 Tal Nisan 2017-03-06 16:10:11 UTC
Juan, we've been using /vms/{vm_id}/diskattachments to edit ALL of the disk's properties aside for the qcow version as /disks does not allow updating of a disk's properties, to align with that the qcow version should be editable through disk attachments as well

Comment 8 Avihai 2017-03-26 08:01:10 UTC
verified.

Engine :
ovirt-engine-4.1.1.6-0.1.el7.noarch

VDSM:
4.19.6-1