It may be confusing without consulting the docs, but once you set it up it works and also does load balancing for you. If you "hardcoded" via a select which capsule should be used for a host with 1 to 1 mapping as you suggest, you would have that deal with load balancing manually and even then it wouldn't be based on current load on the capsules. Not even mentioning the chore of maintaining the right balance with 1000s of hosts, especially if they're being dynamically reprovisioned.

I'm not opposed to the idea, but we may need to think it through.

(In reply to Adam Ruzicka from comment #1)
> It may be confusing without consulting the docs, but once you set it up it
> works and also does load balancing for you. If you "hardcoded" via a select
> which capsule should be used for a host with 1 to 1 mapping as you suggest,
> you would have that deal with load balancing manually and even then it
> wouldn't be based on current load on the capsules. Not even mentioning the
> chore of maintaining the right balance with 1000s of hosts, especially if
> they're being dynamically reprovisioned.
> 
> I'm not opposed to the idea, but we may need to think it through.

Very good point. With this in mind, how about we approach this with a crawl, walk, run mindset.
- At first we provide a way to hard set the execution capsule to be the Satellite's internal capsule for execution for running the "Configure cloud connector" playbook. 
AND/OR
Update documentation/KCS with a working/supported way to configure Capsules to run this playbook against the Capsule server
AND
Wait for RFE 1824835 to conclude

- Next would be a provide a functionality to set the execution Capsule on each host. The deliminators for the Capsules that show up on the drop down list could be as follows:
1. Load Balanced Capsules excluded
2. If host has Organization set, provide list with the difference from 1 and this Org list
3. If host has Lifecycle environment set, provide list with the difference from 2 and this LCE list
(Subnets are assigned to Orgs and LCEs respectively, so these facts will also limit the subnets as well)
4. If host has subnet set on multiple nics, the difference from 3 and this will be shown (subnets with REX enabled)
5. If host has multiple nics with multiple subnets with REX, Capsules based on difference from 4 and the subnet on the nic marked primary will be shown

As this process heavily weights around the configurations of the subnets, I would recommend that 1 of the 2 options are used in deciding on the display for this function:
1: Display the list of Capsules as a check box selection list/table view and have Capsules not available for selection greyed out on the Primary nic configuration screen of the Interfaces tab on the edit host screen or the host tab or a new tab for the host edit screen
2: Provide a tool-tip/status-indicator/check-list item where it can clearly be shown as to why a capsule is greyed out for selection and/or why the capsule is being considered the REX capsule for the job.

In the run phase, we could include functionality for the load balancing of capsules as perhaps a group name or something for those with the functionality of failover LB capsules.
OR
LB capsules could just not be considered since this function would essentially be reverting the functionality the user has implemented.

Please let me know if anything is misunderstood or needs to be better defined.

> 1. Load Balanced Capsules excluded

What exactly do you mean by this?

> 3. If host has Lifecycle environment set, provide list with the difference from 2 and this LCE list (Subnets are assigned to Orgs and LCEs respectively, so these facts will also limit the subnets as well)

The LCE-subnet association doesn't sound familiar. Is this something we already have or a part of the proposal?

> 2: Provide a tool-tip/status-indicator/check-list item where it can clearly be shown as to why a capsule is greyed out for selection and/or why the capsule is being considered the REX capsule for the job.

Where exactly would this be?

Sorry for the delayed replied, got busy with moving. If this bugzilla was closed due to inactivity, I ask to please reopen and reconsider.

(In reply to Adam Ruzicka from comment #3)
> > 1. Load Balanced Capsules excluded
> 
> What exactly do you mean by this?
As setting a specific Capsule to execute a job would defeat the purpose of load balancing capsules, then if the capsules are load balanced, the capsule can be excluded from the set list as an individual and/or be set as a group name.
The difference would be something like this example:
5 Capsules on 1 Satellite:
capsuleA and capsuleB are LB1
capsuleC and capsuleD are LB2
capsuleE is by itself
If a client was to see the job execution capsule drop down, it would show 3 options (assuming the capsules met the requirement for the running of the client job):
**LB1**
**LB2**
**capsuleE**
This is my idea from a RUN phase of this implementation. During the CRAWL/WALK phase, LB capsules could be excluded because we may not want the option to hard set a group of capsules at all.
> 
> > 3. If host has Lifecycle environment set, provide list with the difference from 2 and this LCE list (Subnets are assigned to Orgs and LCEs respectively, so these facts will also limit the subnets as well)
> 
> The LCE-subnet association doesn't sound familiar. Is this something we
> already have or a part of the proposal?
Sorry I may have over assumed on this idea. My thought was that having a subnet on a Capsule for a client that is assigned to a lifecycle environment that is not assigned to the same capsule server would be pointless. But this may not be the case if the capsule/environment is meant only for provisioning of system or to provide a subnet.
A better summarization of this idea would be if the factors chosen on the edit/create host list don't comply with the options of certain capsules, then those capsules would not be shown on the list for a job capsule.
Example:
If clientA sets a value (organization, lifecycle, hostgroup, etc) that doesn't comply with the settings of a Capsule (like a capsule that doesn't have that organization) that capsule would not be included on the drop down for the job capsule.
Image link for the edit host screen that I'm talking about: https://image.op.redhat.com/view/1uT17tKGg
>
> > 2: Provide a tool-tip/status-indicator/check-list item where it can clearly be shown as to why a capsule is greyed out for selection and/or why the capsule is being considered the REX capsule for the job.
> 
> Where exactly would this be?
This could be a "?" or "i" tooltip icon next to the label for the dropdown box that could be hover active to provide a link to documentation like:
https://image.op.redhat.com/view/BIxlStKMR

Please let me know if you have any questions.

The RFE triage team have evaluated this request, and while it's a valid request, we are closing this as it isn't being prioritized to fix in the next several releases.
If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support.
Thank you