Description of problem:
When registering to a load-balanced capsule set, the client will use the LB server name for the request to install the katello-ca-consumer RPM. Based on the workflow of the LB, the request will then be sent to a Capsule in the LB set and download that RPM. Currently, this is a symlink called 'katello-ca-consumer-latest' that points to an RPM called 'katello-ca-consumer-<CapsuleHostname>.noarch.rpm'. This RPM contains the script to set the rhsm.conf to the hostname of the registration to the Capsule the RPM derives from.
# head -n5 ./usr/bin/katello-rhsm-consumer 
#!/bin/bash

set -e

KATELLO_SERVER=capsule1.redhat.com

This request is to include a 2nd RPM, created at the time of including the Capsule into an LB set so that it will create an RPM with the LB hostname on it. This would allow the current workflow of systems needing to register or re-register to an LB Capsule set to be simplified even further.

How reproducible:
n/a

Steps to Reproduce:
1.
2.
3.

Actual results:
Current Manual Registration Method:
1. Remove the katello-ca-consumer package if it is installed:
# yum remove 'katello-ca-consumer*'

2. Install the katello-ca-consumer package from the load balancer:
# rpm -Uvh \
http://loadbalancer.example.com/pub/katello-ca-consumer-latest.noarch.rpm

3. Register the client and include the --serverurl and --baseurl options:
# subscription-manager register --org=Your_Organization \
--activationkey=Your_Activation_Key \
--serverurl=https://loadbalancer.example.com:8443/rhsm \
--baseurl=https://loadbalancer.example.com/pulp/repos

Expected results:
*NOTE: a new symlink to the latest LB RPM could be used like the example below*
New Manual Registration Method:
1. Install the katello-ca-consumer package from the load balancer:
# rpm -Uvh \
http://loadbalancer.example.com/pub/katello-ca-consumer-lb-latest.noarch.rpm
Version-Release number of selected component (if applicable):

2. Register the client:
# subscription-manager register
or with an AK:
# subscription-manager register --org=Your_Organization \
--activationkey=Your_Activation_Key

Additional info:
This would solve a couple of customer constraints and issues while adding value as noted below:

1. By have the dual RPM, customers could assign clients to Capsules statically and additional clients through an LB.
Example:
Capsules in the USA and China
Clients in the USA, India, and China
Clients relative to the location could be registered to the closest Capsule while clients further away could be registered through the load balancer.

2. Setting the LB hostname in the RPM would prevent additional actions/commands needed from users, lowering the chance for error.

3. For any unique scenarios where the client would have to reinstall the katello-ca-consumer RPM, the name of the RPM for an LB Capsule set would be the same across all Capsules resulting in the 'yum/dnf update' command being a single point of resolution as opposed to 'yum remove katello-ca-consumer-*; yum install katello-ca-consumer-latest'