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.
Christian Could you describe in more deatail, how the layout for the specific host that is failing looks like? I'm mostly interested into what proxies is the the host attached to? Is the satellite server in some of them? I also recommend setting remote_execution_global_proxy to false, as if there are not proxies found via the proxy association, we continue via organization/location assignment.
(In reply to Ivan Necas from comment #1) > Christian Could you describe in more deatail, how the layout for the > specific host that is failing looks like? > > I'm mostly interested into what proxies is the the host attached to? Is the > satellite server in some of them? > > I also recommend setting remote_execution_global_proxy to false, as if there > are not proxies found via the proxy association, we continue via > organization/location assignment. Hi, Here would be a typical scenario. Satellite server and Capsule are in 2 different Network. Satellite server is in Subnet 192.168.1.0/24 Capsule Server is in Subnet 172.16.1.0/24 Only the required ports are open between Satellite and Capsule. Satellite and Capsule are both having the SSH feature enabled. Clients in the Subnet 192.168.1.0/24 are registered to the Satellite Server. Clients in the Subnet 172.16.1.0/24 are registered to the Capsule Server. There is no possible network connection between the 2 Subnets, except for Satellite <-> Capsule Communication. Hosts do not all have a Subnet configured and are not all Managed. Hosts are all in the same Organization, but they do not necessarly have a Location specified. --- By example, in my scenario I have 2 Hosts reporting to Satellite and 5 Hosts reporting to the Capsule. I've edit all the hosts to make sure they do not have a Subnet specified and are Unmanaged. When I run a job on the 7 Hosts, I have a Success rate from 71% to 86%, no matter what is the combination of these settings: (remote_execution_fallback_proxy remote_execution_global_proxy) On the failed Host, I can see that the connection was initiated from the Satellite, instead of the Capsule. https://satellite.domain.com:9090 The RFE is to have more flexibility about how to specify a Capsule, without having to edit all the Hosts manually to set the Subnet. Let me know if this need more details. Thanks -Christian
With remote_execution_fallback_proxy true and remote_execution_global_proxy, the proxy should be determined from the proxies assigned to the host? For the failing host, is there a chance there would be the proxy on the satellite used for any feature? Could we ask the customer to run this and report the output: User.current = User.anonymous_api_admin # replace host.example.com with the client machine with issues Host.where(:name => "host.example.com").first.smart_proxies.map(&:name) My suspicion is there is the satellite's proxy assigned to the host via some association, and that's why it would get to the list of proxies. We need to understand the environment better before we can know what to enhance, as we tried to put a lot of flexibility into the selection already and I'm a bit surprised there would not be a mode that would work for the customer.
Hi Ivan, So actually I see the following 3 behaviors. --- 1. When fully provisioning a Host using Satellite, but via the Capsule, we will have the following 2 smart_proxies: => ["capsule.domain.com", "satellite.domain.com"] Note: As we use Subnet Configuration for provisioning, this is will be override by the Subnet settings which select the appropriate REx Capsule. --- 2. When registering an existing Host to the Capsule, via subscription-manager only, here is the smart_proxies: => ["satellite.domain.com"] --- 3. For the same existing Hosts that was just registered via rhsm, after configuring the puppet agent, the smart_proxies are updated to the following: => ["capsule.domain.com", "satellite.domain.com"] From what I saw from customer installation and from my lab testing, without using Subnet configuration it is difficult to figure out which Capsule will be use for the REx job. Thanks -Christian
I was under impression, that we assign the proxy according the one that we are registering the host though. Another thing that can be used is setting a location via puppet custom fact, and making sure just the right capsule is in the location of the host. This should work with remote_execution_fallback_proxy false and remote_execution_global_proxy true
Hi, So the idea of this RFE is the allow more flexibility for the users in future releases of Satellite. For the particular cases we have faced, the workaround was to use Subnet and it was successful. But the customer want to have more global settings and default behavior. Now, we want to make sure that we improve this from now on. By example, as we see, when a client is registered as a Content Hosts via a Capsule, the first smart_proxies configured will be Satellite server. => ["satellite.domain.com"] When we add the puppet agent, the host will end up with 2 smart_proxies: => ["capsule.domain.com", "satellite.domain.com"] So I think we can take 2 approach: 1) Put some effort on this RFE and see how we can make, by example "Content Source" server to be the one used by REx. Or maybe have a global settings to enable this behavior. We can also make an option to use the Puppet Master as the REx Capsule. 2) Fill a bug because when we register a Content Host to Satellite, the Host created gets the Satellite server to be the smart_proxy. Are you able to confirm you see the same behavior on your side? What would you suggest so that we improve the customer experience concerning Remote Execution feature when defining the proper Capsule is critical for the customer? Thanks
Needinfo back to Ivan.
I vote for 2 and closing this bug in it's favor, as it's more systematic rather than trying to tweak the selection of prxies further: there is already quite a lot of options that people can get lost in
Chrsitian, does comment 8 seem ok?
I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1570808 to cover the bug outlined in 2) of https://bugzilla.redhat.com/show_bug.cgi?id=1508153#c6
Per ivans comment, I am closing this out as WONTFIX in favor of https://bugzilla.redhat.com/show_bug.cgi?id=1570808.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days