Created attachment 1179888 [details] Logs from engine, hosts, art Description of problem: You can see links from V3 api: <link href="/ovirt-engine/api/v3/templates/03035598-bde1-460c-81ee-9f473c11d416/cdroms" rel="cdroms"/> <link href="/ovirt-engine/api/v3/templates/03035598-bde1-460c-81ee-9f473c11d416/graphicsconsoles" rel="graphicsconsoles"/> <link href="/ovirt-engine/api/v3/templates/03035598-bde1-460c-81ee-9f473c11d416/nics" rel="nics"/> <link href="/ovirt-engine/api/v3/templates/03035598-bde1-460c-81ee-9f473c11d416/permissions" rel="permissions"/> <link href="/ovirt-engine/api/v3/templates/03035598-bde1-460c-81ee-9f473c11d416/tags" rel="tags"/> <link href="/ovirt-engine/api/v3/templates/03035598-bde1-460c-81ee-9f473c11d416/watchdogs" rel="watchdogs"/> <link href="/ovirt-engine/api/v3/templates/03035598-bde1-460c-81ee-9f473c11d416//03035598-bde1-460c-81ee-9f473c11d416/disks" rel="disks"/> disks link is bad. And our automation failed when we adding template and copy disk to SDs Version-Release number of selected component (if applicable): 4.0.1-2 How reproducible: Steps to Reproduce: 1. add template 2. copy template disk to another SD with rest API V3
Impact on automation: When we build our GEs, we are using the template from which we copy disk to all SDs, and then we create some VMs depend on this template and template's disk. So if we have bed link in API, our code cannot work with it and our GE-builder job cannot build GE and the whole job is failing cause of this bug. We have also builder for V4 api, but there was change with disks -> diskattachments so we didn't align with this change yet(in progress).. so we cannot also build GE with V4 API. So when we don't have right built our GEs we cannot run our Tier tests on them.
Is this Infra or Storage?
(In reply to Yaniv Kaul from comment #2) > Is this Infra or Storage? The starting point should be Storage. Each vertical is in charge of its own REST APIs (in this case - disks belong to Storage). If we dig around and find there's something wrong with the infrastructure, we can always move it. Tal - can you take a look please? This looks suspiciously like it's related to commit 88eb98dd6d67a7fac003cd737d466866c865c130, but I'm not sure. Thanks!
Not related to this commit, the problem lies within the V3TemplateHelper/V3VMHelper links calculation. Note for the QE contact who will test it - this also occurs for VMs so please check it there as well
We also see 'null' instead of 'disks' in this request: GET request content is -- url:/ovirt-engine/api/templates/03035598-bde1-460c-81ee-9f473c11d416/disks Response body for GET request is: <disks> <disk href="/ovirt-engine/api/templates/03035598-bde1-460c-81ee-9f473c11d416/null/c04ad884-7329-476d-8abd-9b838233cce0" id="c04ad884-7329-476d-8abd-9b838233cce0"> <actions> <link href="/ovirt-engine/api/templates/03035598-bde1-460c-81ee-9f473c11d416/null/c04ad884-7329-476d-8abd-9b838233cce0/export" rel="export"/> <link href="/ovirt-engine/api/templates/03035598-bde1-460c-81ee-9f473c11d416/null/c04ad884-7329-476d-8abd-9b838233cce0/copy" rel="copy"/> </actions> i assume it will be covered in the fix, but wanted to make sure
We still see null in template's disk links in 4.0.2 : <disk href="/ovirt-engine/api/v3/templates/ee54ddf7-f8e5-4345-876f-9538900d8642/null/8abfcc70-849b-4afb-9c56-44b0db685c74" id="8abfcc70-849b-4afb-9c56-44b0db685c74"> http://pastebin.test.redhat.com/395036
see comment #6
(In reply to Petr Balogh from comment #6) > We still see null in template's disk links in 4.0.2 : > <disk > href="/ovirt-engine/api/v3/templates/ee54ddf7-f8e5-4345-876f-9538900d8642/ > null/8abfcc70-849b-4afb-9c56-44b0db685c74" > id="8abfcc70-849b-4afb-9c56-44b0db685c74"> > http://pastebin.test.redhat.com/395036 Build information, complete engine log are usually needed. Nelly - can we ensure this is indeed not fixed in 4.0.2? (is it reproduced elsewhere as well?)
as Petr wrote it is still failing in 4.0.2 build: rhevm-4.0.2-0.1.rc.el7ev.noarch and we see it in 2 environments which were provisioned i can attach the logs again, but probably wont be different than the previous logs
adding more info: the patch which was supposed to fix it causes the following: passing /ovirt-engine/api/v3/templates/ results in <link href="/ovirt-engine/api/v3/templates//00000000-0000-0000-0000-000000000000/disks" rel="disks"/> (double slash) passing /ovirt-engine/api/v3/templates results in <link href="/ovirt-engine/api/v3/templates/00000000-0000-0000-0000-000000000000/disks" rel="disks"/> while in vms its the opposite: /ovirt-engine/api/v3/vms results in <link href="/ovirt-engine/api/v3/vms9b9cab84-3624-4f4b-9aee-fe4bf2400361/disks" rel="disks"/> (missing slash) and passing /ovirt-engine/api/v3/vms/ results in <link href="/ovirt-engine/api/v3/vms/9b9cab84-3624-4f4b-9aee-fe4bf2400361/disks" rel="disks"/> so the behavior is inconsistent in addition to this issue, the related problem mentioned in comment #5 & comment #6 - null link when entering template/UUID/disks wasnt fixed
Patch 61292 should solve the double/no slashes before the disks part of the link. The nulls issue still needs to be solved.
Juan is already working on a solution for it on a different thread. Marking as depend on 1358860 (not closing since this bug is a RHEV bug and 1358860 is an ovirt bug). Juan, do you want to take it from here?
Yes, I take it, thanks Idan.
Juan - is there anything else missing here, or can this one be moved to MODIFIED too?
Can't move to MODIFIED yet, the patches still need to be merged to the 4.0 and 4.0.2 branches. We can also close as duplicated of bug 1358860.
All the required changes are now merged to the 4.0.2 branch, so this is now MODIFIED.
Verified on ovirt-engine-4.0.2.1-0.1.el7ev.noarch The link to disks collection under vms and templates is now correct
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://rhn.redhat.com/errata/RHEA-2016-1743.html