1. Proposed title of this feature request

HostedCluster configurable knob for upstream update service

2. What is the nature and description of the request?

XCMSTRAT-513 includes OTA-1185 pitching local update services in managed regions.  However, HyperShift currently forces ClusterVersion spec.upstream empty.  This RFE requests exposing upstream as a configurable knob in HostedCluster spec.

3. Why does the customer need this? (List the business requirements here)

The knob would allow HyperShift clusters to hear about and assess known issues with updates in environments where the default https://api.openshift.com/api/upgrades_info update service was not accessible, or in which an alternative update service was desired for testing or policy reasons. This includes OTA-1185, mentioned above, but would also include any other instance of disconnected/restricted-network use. The alternative for folks who want HyperShift updates in places where api.openshift.com is inaccessible are:

• Don't use an update service and manage that aspect manually. But the update service declares multiple new releases each week, as well as delivering information about known risks/issues for local clusters to evalute their exposure. That's a lot of information to manage manually, if folks decide not to plug into the existing update service tooling.
• Run a local update service, and fiddle with DNS and X.509 certs so that packets aimed at api.openshift.com get routed to your local service. This one requires less long-term effort than manually replacing the entire update service system, but it requires your clusters to trust an X.509 Certificate Authority that is willing to sign certificates for your local service saying "yup, that one is definitely api.openshift.com".

4. List any affected packages or components.

One possible data path would be:

1. HostedCluster (management cluster).
2. HostedControlPlane (management cluster).
3. ClusterVersion (hosted API).
4. Cluster-version operator container (managment cluster).

that pathway would only require changes to the HyperShift repo.  But to avoid URI passing through the customer-accessible hosted API, we could implement with a path like:

1. HostedCluster (management cluster).
2. HostedControlPlane (management cluster).
3. Cluster-version operator Deployment command line option (management cluster).
4. Cluster-version operator container (managment cluster).

and that pathway would involve changes in both the CVO (to add the new command line option) and HyperShift (for the earlier steps in the path).