Bug 1679158
Summary: | [REST] Fix Link To Network Under Cluster | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | msheena |
Component: | BLL.Network | Assignee: | Ori Liel <oliel> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | msheena |
Severity: | urgent | Docs Contact: | |
Priority: | high | ||
Version: | 4.3.0 | CC: | bugs, dholler, mburman, mperina, msheena, oliel |
Target Milestone: | ovirt-4.3.2 | Keywords: | Automation, AutomationBlocker, Regression |
Target Release: | --- | Flags: | pm-rhel:
ovirt-4.3+
pm-rhel: blocker+ |
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | ovirt-engine-4.3.2 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-03-19 10:03:24 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
msheena
2019-02-20 13:35:19 UTC
It seems that via the https://network-ge-1.scl.lab.tlv.redhat.com/ovirt-engine/api/clusters/7f690914-6c2b-4e49-92f4-7751af6d63ab/networks/cc7f33c4-4e6e-400d-b273-10d1ca61083b URL it is possible to update the roles, however when performing a GET https://network-ge-1.scl.lab.tlv.redhat.com/ovirt-engine/api/clusters/7f690914-6c2b-4e49-92f4-7751af6d63ab/networks then the href associated with each network is: /ovirt-engine/api/datacenters/648ea7c6-d34d-4b6e-a5b5-ac997ae94db9/networks/8f68d575-f8f6-4fa8-aba7-db07805c1c8c which is not working for update Did this request work in older versions? Ori, is the scenario expected to work and is this related to bug 1645890 ? Did this request work in older versions? I tested on 4.2.8.3-0.1.el7ev and it works. What also happens is that upon performing a GET /ovirt-engine/api/clusters/dbba8bf2-f402-11e8-be47-00163e7ba003/networks the network's href points to: /ovirt-engine/api/clusters/dbba8bf2-f402-11e8-be47-00163e7ba003/networks/ffd80c4e-2d09-47b8-b95d-bbf49c164dca which as I added in comment #1 works perfectly well, so the question is if it should point to the href that works or if the new href is not working properly becuase it does report 200[OK] upon updating, but doesn't change roles (other then vm role) Ori, is the scenario expected to work and is this related to bug 1645890 ? Sounds like two separate issues: 1. GET ...api/clusters/xxx/networks returns networks with href ...api/datacenters/xxx/networks instead of ...api/cluster/xxx/networks. This is probably related to a family of bugs which have inevitably popped-up after https://gerrit.ovirt.org/#/c/82294. So yes, it sounds like it's similar to bug 1645890, and this has an easy fix. 2. PUT .../api/datacenters/networks/yyy providing display usage returns 200 but the display usage is ignored Before we go any further I want to make sure I understand - Moshe, when you say it worked on 4.2.8.3-0.1.el7ev, do you mean that PUT .../api/datacenters/networks/yyy worked, or do you mean that the flow worked because ...api/clusters/xxx/networks/yyy is the link which was returned, and PUT on that link (as opposed to .../api/datacenters/networks/yyy) works? My intention was that the networks were mapped with the clusters resource instead of the datacenters one, and this is how it should be according to the documentation: http://ovirt.github.io/ovirt-engine-api-model/master/#types/network/attributes/usages So the urgency is more a matter of the href pointing to an href other than the one it should point to. On another note, there is room to consider the fact that using PUT on the datacenters resource returns 200 and ignores the network usages, however, this is of lesser importance at the moment if any since there is no potential of harming data here. Alright, then IIUC the urgent issue is that GET ...api/clusters/xxx/networks will return networks with href ...api/cluster/xxx/networks. I will shortly submit a patch fixing this This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP. Verified on: 4.3.2-0.1.el7 This bugzilla is included in oVirt 4.3.2 release, published on March 19th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.2 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. |