Bug 1411472

Summary:	Content Host registration may make bad choice of Primary/RemoteExec interface if multi-nic
Product:	Red Hat Satellite	Reporter:	Dylan Gross <dgross>
Component:	Hosts	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.2.6	CC:	ahumbe, bkearney, dgross, hmore, hshukla, inecas, jcallaha, ktordeur, mhulan, nshaik
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-09-04 18:05:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dylan Gross 2017-01-09 19:50:43 UTC

Description of problem:

   When registering a Content Host with multiple NICs via subscription-manager, the Satellite may choose a NIC as the primary interface that is inaccessible or unroutable.

   By default the Remote Execution interface is the same as the primary interface, and the primary interface is just the first interface with a link.  

   This means that if the first device with a link detected is a private network not accessible to the satellite, it will be set at the primary interface and the Remote Execution interface, and Remote Executions will fail until a better interface is manually selected.

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


How reproducible:


Steps to Reproduce:
1.  Create a system with a 1st interface on a private network space
2.  Add a second interface that is routable to the Satellite
3.  Register the content host through subscription-manager
4.  On the host page for that host, under "NICs" tab, observe that Primary interface was the first interface that is inaccessible via the Satellite.

Actual results:

   Primary and Remote Execution interface is set to the first one it finds with a link, regardless of accessibility.

Expected results:

   A usable, accessible interface is chosen as Primary/RemoteExecution interface

Additional info:

   Perhaps this could be determined by the interface that is connecting at registration time, or even have an /etc/rhsm/facts/*.facts override that lets you specify which interface is primary.

Comment 3 Marek Hulan 2017-01-10 11:03:06 UTC

In this case I think changing remote_execution_fallback_proxy setting to yes (Administer -> Settings -> RemoteExecution) would help. AFAIK it would go over all interfaces, checking the attached proxy via subnet and using it if it has REX feature available. A good explanation of the determine process can be found in upstream manual at https://theforeman.org/plugins/foreman_remote_execution/0.3/index.html#4.1Determiningthesmartproxyforhost and the product documentation can be found at https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/host-configuration-guide/113-configuring-global-settings

Comment 5 Dylan Gross 2017-01-10 14:54:49 UTC

Regarding the remote_execution_fallback_proxy:   I set it to 'yes' on my lab satellite, and attempted to 'subscription-manager register' host that had multiple NICs.

eth0 was a private network (unaccessible to the Satellite) with link up 
eth1 was public and accessible to satellite

It still chose eth0 as it's Primary and Remote Execution interface for the host.   

I then attempted a job run against the host, in case the setting had effects at the time of job run, but it still timed out trying to reach the IP of eth0.

My (possibly incorrect) interpretation of that parameter has always been that if the registered host's current capsule did not have Remote Execution capabilities,  it would search for another capsule in the environment that does, when a Remote execution was attempted.   However, if my interpretation is correct, that would still not allow it to exec against the private IP that is chosen for the host's REX interface.

Comment 6 Marek Hulan 2017-01-10 15:12:44 UTC

Ah, you're right about the setting, I mixed that sorry.

Comment 10 Marek Hulan 2017-07-21 07:08:58 UTC

The question is how should we detect the primary or rex interface based on incoming facts. How would you pick the right interface from array of ip addresses and identifiers? We'd have to let users somehow specify which interface they consider as primary/provision/rex. Maybe through some custom fact.

Comment 11 Nagoor Shaik 2018-07-24 10:15:16 UTC

(In reply to Marek Hulan from comment #10)
> The question is how should we detect the primary or rex interface based on
> incoming facts. How would you pick the right interface from array of ip
> addresses and identifiers? We'd have to let users somehow specify which
> interface they consider as primary/provision/rex. Maybe through some custom
> fact.

Hi Marek,

IMHO, I think of 2 possibilities here.

1. Create a new option in subscription-manager utility to let the end-user choose the primary nic which can be used for REX as well.

2. Enhance bootstrap.py script to allow an option for selecting the primary interface, which can be updated through an API call.

Comment 12 Bryan Kearney 2018-09-04 18:05:58 UTC

Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.

Comment 15 Bryan Kearney 2018-11-06 19:11:25 UTC

Some notes on this

*  bootstrap.py already supports from comment 11 "2. Enhance bootstrap.py script to allow an option for selecting the primary interface, which can be updated through an API call." 

* see Providing the IP address to Foreman section of  https://github.com/Katello/katello-client-bootstrap/blob/master/README.md


Given this, and the priority of other items, we will keep this as WONTFIX.