Bug 1357987
| Summary: | In v4, GET to /disks/{disk:id} returns property <active> | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Carlos Mestre González <cmestreg> |
| Component: | RestAPI | Assignee: | Idan Shaby <ishaby> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Raz Tamir <ratamir> |
| Severity: | low | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.0.1.1 | CC: | acanan, amureini, bugs, cmestreg, ratamir, sbonazzo, tnisan, ylavi |
| Target Milestone: | ovirt-4.0.2 | Flags: | rule-engine:
ovirt-4.0.z+
rule-engine: blocker+ ylavi: planning_ack+ amureini: devel_ack+ acanan: testing_ack+ |
| Target Release: | 4.0.2.4 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-08-12 14:30:51 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: | |||
The disk "active" and "interface" attributes have been moved to the disk attachment, so they should now be removed completely from the "Disk" type, first in the specification of the API, then in the implementation. (In reply to Juan Hernández from comment #1) > The disk "active" and "interface" attributes have been moved to the disk > attachment, so they should now be removed completely from the "Disk" type, > first in the specification of the API, then in the implementation. Yup, agreed. Tal? Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone. (In reply to Allon Mureinik from comment #2) > (In reply to Juan Hernández from comment #1) > > The disk "active" and "interface" attributes have been moved to the disk > > attachment, so they should now be removed completely from the "Disk" type, > > first in the specification of the API, then in the implementation. > Yup, agreed. > Tal? Agreed Hi Tal, I encountered another issue that I think is not consistent relevant to active. Trying to attach a disk: <disk_attachment > <interface>ide</interface> <active>true</active> <disk id="5a8d9ebf-05f0-4eb7-9a73-f29ca2c1d1fd"> </disk> </disk_attachment> ===> disk is attached but not activated <disk_attachment > <interface>ide</interface> <disk id="5a8d9ebf-05f0-4eb7-9a73-f29ca2c1d1fd"><active>true</active> </disk> </disk_attachment> ==> disk is attached and activated since <active> only makes sense with disk attachment and is return in diskattachment GET, shouldn't this property be also pass as disk_attachment instead of inside the disk to make it consistent? Carlos, there's might be a point here but perhaps open another but to discuss that? Hi Tal, According to Juan's comment, active attribute should be removed from Disk type, shouldn't this also 'fix' the issue I mentioned on comment 5? why open a new bug? The property was indeed removed from the disk, I meant that if it doesn't work as expected while sending it through the attachment please open a separate bug for that Verified on ovirt-engine-4.0.2.4-0.1.el7ev.noarch |
Description of problem: In v4, GET to /disks/{disk:id} returns property <active> (when this is now part of /vms/{vm:id}/diskattachments/{disk:id}, what is worst, is always return as 'false' even though the disk is active. Version-Release number of selected component (if applicable): rhevm-4.0.1.1-0.1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. Create a vm with a disk attached to it 2. GET /ovirt-engine/api/v4/vms/{vm:id}/diskattachments shows the disk as active 3. GET /ovirt-engine/api/v4/disk/{disk:id}/ Actual results: the values return contain the property: <active>False</active> Expected results: No property <active> is returned since this is only meaningful on with the relation with the vm (diskattachments)