-
Bug
-
Resolution: Done
-
None
-
6.2.12
Description of problem:
Users who need to have Remote Execution connecting from specific Capsule(s) are lacking some flexibility about how they can achieve this.
Version-Release number of selected component (if applicable):
6.2.12
How reproducible:
100%
Steps to Reproduce:
1. Have a Satellite 6.2 with Remote Execution Enabled
2. Have a Capsule with Remote Execution Enabled
3. Make sure the Satellite and the Capsule are in 2 different Subnets so that the ssh connections can't reach the Hosts registered from the Capsule directly from the Satellite server.
4. Have 4 to 5 Hosts Registered/Configured to the Capsule and have them REx ready.
These Hosts must be Unmanaged by Satellite and have no Subnet configured on their Network Interface. The reason why we need multiple Hosts for this test is to rule out any misleading behavior that can be caused by "remote_execution_fallback_proxy" settings. This setting will make allow some connections to be initiated by the Capsule, but it's because of the round-robin effect, and not because we explicitly configure it.
5. Run a Job on these hosts.
Actual results:
At least 2 out of 5 hosts, will fail with the following error because the connection is sometime initiated from Satellite server:
Errno::ENETUNREACH Network is unreachable - connect(2)
Actually the only solution to get an expected behavior is to define Subnets in which you will assign specific Capsule(s) for Remote Execution. However, this assumes that all the Hosts are Managed and have a Subnet configured. Most of the users registering existing clients to Satellite do not configure the Subnet on their Hosts.
Expected results:
There should be some options available to use, by example, the the Puppet Master as the Remote Execution Capsule, and/or the Content Source. Or any other flexible configuration. This will avoid a lot of manual configurations.
- external trackers