Bug 1804263
Summary: | Mapping fail when selecting public network not directly belongs to the selected project. | ||
---|---|---|---|
Product: | Red Hat CloudForms Management Engine | Reporter: | Md Nadeem <mnadeem> |
Component: | V2V | Assignee: | Fabien Dupont <fdupont> |
Status: | CLOSED ERRATA | QA Contact: | Md Nadeem <mnadeem> |
Severity: | medium | Docs Contact: | Red Hat CloudForms Documentation <cloudforms-docs> |
Priority: | high | ||
Version: | 5.11.3 | CC: | bthurber, dmetzger, fdupont, mturley, simaishi |
Target Milestone: | GA | Keywords: | ZStream |
Target Release: | 5.11.8 | Flags: | simaishi:
cfme-5.11.z+
|
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 5.11.8.1 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-09-30 14:01:06 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | Bug | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | V2V | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1822318 |
Comment 2
Fabien Dupont
2020-02-19 14:52:00 UTC
Fabien, I'm not sure what would cause that error, but I think it must be on the backend, there's nothing different about the request the UI makes for admin and non-admin projects. I can reproduce the issue, and comparing the POST request that failed with a successful POST request creating a mapping for an admin project, the requests are exactly the same except for the URIs of the mapping items. So it's something about the presence of a non-admin project in the mapping items. In case this is helpful information, it appears that after I get the 400 error, I can reload the mappings list and see that a mapping object was actually created, but without any transformation_mapping_items. It appears in the list, but causes errors and displays 0 associated objects. So apparently the backend is successfully creating the object and then trying to add the mapping items and failing at that point? Has it been reproduced on 5.11.5? @fabien Yes, it is reproducible in Version 5.11.5.2 as well I can't reproduce this bug. I have deployed CloudForms 5.11.5.2 on OpenStack 14, in a non-admin project. I have created the VMware and OpenStack providers in CloudForms and waited for the inventory to refresh. I have created an Infrastructure Mappings that maps: - cluster named "V2V-Cluster" to project named "fdupont" (non-admin) - datastore named "NFS_Datastore" to volume type named "tripleo" - network named "VM_DHCP_Network" to network named "network-fdupont" New commit detected on ManageIQ/manageiq/ivanchuk: https://github.com/ManageIQ/manageiq/commit/a47b67d43bda7deac5dad4f3c0dbc8ec8edb3a00 commit a47b67d43bda7deac5dad4f3c0dbc8ec8edb3a00 Author: Adam Grare <agrare> AuthorDate: Wed Jul 15 19:12:59 2020 +0000 Commit: Satoe Imaishi <simaishi> CommitDate: Wed Aug 19 15:03:57 2020 +0000 Merge pull request #20238 from fdupont-redhat/v2v_bz1804263 [V2V] Allow OpenStack public networks in transformation mappings (cherry picked from commit d94456d79e9b8379702f9cadfaf4108f99b7ba88) https://bugzilla.redhat.com/show_bug.cgi?id=1804263 app/models/transformation_mapping_item.rb | 1 + spec/models/transformation_mapping_item_spec.rb | 29 +- 2 files changed, 20 insertions(+), 10 deletions(-) Follow-up PR: https://github.com/ManageIQ/manageiq/pull/20551 Backported to ivanchuk branch commit 947a00e19c211e0de45b686dc4f9a28b31726583 Author: Adam Grare <agrare> Date: Tue Sep 15 09:53:59 2020 -0400 Merge pull request #20551 from fdupont-redhat/bz_1804263_2 Accept shared networks instead of public networks in mapping (cherry picked from commit e5986d44a2a84089fc80977567ec4d60ec87b7eb) Verified on CFME Version 5.11.8.1 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 (Moderate: CloudForms 5.0.8 security, bug fix and enhancement update), 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://access.redhat.com/errata/RHSA-2020:4134 |