Description of problem: Disk attachments in: api/storagedomains/{storage_id}/vms/{vm_id}/diskattachments and api/storagedomains/{storage_id}/vms/{vm_id}/diskattachments/{attachment_id} does not contain links, attempting to map this links wrongly references api/vms/{vm_id} Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Is there any plan to resolve this issue Juan? This is not specific for the DiskAttachment type, if you notice the links of the VM and disks within a VM from an export domain point you to the location of api/vms or api/disks which is not right as we are talking about a VM in an export domain
Yes, the plan has several parts, some intended for a more global solution to the problem of creating links: 1. Create a mechanism to simplify creation of 'href' attributes in type safe way. This will be code generated from the model that will allow to create the 'href' attributes with something similar to this: import static o.o.e.a.b.HrefBuilderFactory.system; String href = system() .storageDomains() .storageDomain("123") .vms() .vm("456") .diskAttachments() .diskAttachment("789") .build(); The patch that adds this capability to the metamodel is under review: Generate 'href' builders https://gerrit.ovirt.org/69152 2. Untangle the implementation of storage domain related resources. Currently there are several abstract classes involved, and we are reusing some of the instance classes for both virtual machines and templates. That complicates refactoring in this area. I am currently working on simplifying this code. 3. Create the links explicitly in the 'addLinks' method of each resource. This is needed because the mechanism that we currently use in the 'LinkHelper' class isn't flexible enough for this case. I am moving the bug to the infra team as most of the work is API infrastructure.
Verified on ovirt-engine-4.3.0.4-1.el7
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.