Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1660258 - Issue when provision a new Content Host (the network used is different from the selected on the compute profile)
Summary: Issue when provision a new Content Host (the network used is different from t...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Compute Resources - VMWare
Version: 6.4.0
Hardware: All
OS: All
high
high
Target Milestone: 6.5.0
Assignee: Ondřej Ezr
QA Contact: Sanket Jagtap
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-18 00:30 UTC by Waldirio M Pinheiro
Modified: 2019-11-05 22:42 UTC (History)
11 users (show)

Fixed In Version: foreman-1.20.1.25-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-14 12:39:36 UTC
Target Upstream Version:
Embargoed:
oezr: needinfo-

Attachments (Terms of Use)
Readable network name (15.27 KB, image/png)
2019-04-18 08:43 UTC, Sanket Jagtap 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 26280 0 Normal Closed The network used is different from the one visible in the network modal. 2020-11-09 10:23:51 UTC
Foreman Issue Tracker 26307 0 Normal Closed Vmware network comming from subnet guess should not rewrite the one selected on compute profile 2020-11-09 10:23:50 UTC
Red Hat Product Errata RHSA-2019:1222 0 None None None 2019-05-14 12:39:46 UTC

Description Waldirio M Pinheiro 2018-12-18 00:30:42 UTC 
Description of problem:
Error when creating a new Content Host using VMWare Compute Resource. The network information coming from Compute Profile appears to be correct on the webUI but when submitted generate an error (and then we are able to see a diff dvport group as expected)

Version-Release number of selected component (if applicable):
6.4.1

How reproducible:
100% on the customer environment

Steps to Reproduce:
1. Create a Compute Resouce
2. Create a Compute Profile
3. Create a Hostgroup
4. Create a new Content Host and use the hostgroup

Actual results:
Fail with error as below:
"
Unable to save
Failed to create a compute RAILINC-Cary-DEV (VMware) instance vrh7csnellchqd05.railinc.com: ResourceNotAvailable: The resource vim.dvs.DistributedVirtualPort is not available in vim.dvs.DistributedVirtualPortgroup CHQ_Cisco_B_Dswi-DVUplinks-12035. 
"

Expected results:
Create the Content Host without issues.

Additional info:
Comment 4 Marek Hulan 2018-12-19 13:52:19 UTC 
Chris, could you please take a look? My quick guess is that this happens when user tries to use wrong port and portgroup combination. Could you configure something similar in your vmware instance so we have a reproducer?

Waldirio, could you test if it works without using hostgroup/compute profile when you select everything manually? My guess is that something will override the interface network during the host form update. I've seen something similar with oVirt. Also the reproducer would help greatly if Chris can't build one.
Comment 15 Marek Hulan 2019-03-06 07:50:18 UTC 
Waldirio, could you please get the following from customer (of course change credentials and url to their satellite)?

1) curl -u admin:changeme -H "Content-Type: application/json" -H "Accept: application/json" -k https://satellite.example.tst/api/v2/hostgroups/11
2) if the host group has parent, please also get the same for that (change 11 to whatever the parent host group id is
3) curl -u admin:changeme -H "Content-Type: application/json" -H "Accept: application/json" -k https://satellite.example.tst/api/v2/compute_profiles/6
4) record the video of the flow

We still can't reproduce and without that, we can't work on the fix for 6.4. The new version will have resource loading limited to only available resources, so the bug will go away, but this is rather a big change, that can't be backported.
Comment 18 Bryan Kearney 2019-03-08 03:04:39 UTC 
Upstream bug assigned to oezr
Comment 19 Bryan Kearney 2019-03-08 03:04:40 UTC 
Upstream bug assigned to oezr
Comment 20 Marek Hulan 2019-03-08 12:46:49 UTC 
Good news, we believe Ondrej found the cause. We were able to reproduce when we set the subnet's vlanid to number that is also part of the vmware network name. There's some logic that tries to match similarly named network with subnet vlanid, but it only updated part of the form. The fix is simple for cherry-picking and can be backported. This automatching logic was introduced in 6.4, which explains why it worked on 6.3. The patch has been merged upstream today. I'm sorry it took us a long time, but without a reproducer, it wasn't easy.
Comment 23 Ondřej Ezr 2019-03-11 23:55:32 UTC 
I was investigating the problem bit more and the matching introduced in 6.4 is as Marek said for vlanid from selected subnet in the name of vmware network. The matching didn't work properly and that is now fixed. Unfortunately there are two more problems with that. First the matching takes precedence over any other vmware network selection. I have opened a proposal to fix that, so the suggestion based on vlanid would only take effect if the user haven't selected the network in another way (in compute profile or manually). Second that there is no reasonable way to propagate real vlanid from vmware StandardPortGroup to satellite, so the matching is based just on a name of the network, which works just if user follows the naming convention of VLAN<vlanid> on VMware side and can select undesired values if the numers are found in other networks.

Please let us know, if you have some insights, what would be the desired behavior by customer, to cover all the use cases.
Comment 25 Marek Hulan 2019-03-15 12:44:37 UTC 
It would be also good to cherry-pick the patch from https://projects.theforeman.org/issues/26307 which implements autoselecting only when subnet is changed by user interaction either in modal window or by selecting host group when no compute profile is involved. Selecting compute profile sets the network according to how the profile is defined. This should work well even for customer that do not share the vlanid in name of subnet and network.

Therefore, moving back and linking the second issue.
Comment 29 Sanket Jagtap 2019-04-18 08:42:40 UTC 
Build: Satellite 6.5 snap 24 

When we have network associated in compute profile, The compute profile network will be selected. 
But, when we manually update subnet that has a VLAN ID associated. The VLAN ID , would be selected. If not, it would fallback to use the network from compute profile

Also, now the networks are Human readable Name , from Vmware , rather than network ID's.
Comment 30 Sanket Jagtap 2019-04-18 08:43:04 UTC 
Created attachment 1556111 [details]
Readable network name
Comment 32 errata-xmlrpc 2019-05-14 12:39:36 UTC 
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://access.redhat.com/errata/RHSA-2019:1222
Note You need to log in before you can comment on or make changes to this bug.