Bug 1508153

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