User Story:

As a CVO developer, I want to be able to:

• correctly select which CVO manifests are applied based on FeatureSet
• perform the selection through properly implemented CVO logic

so that I can achieve

• desired CVO features are enabled/disabled on the hosted cluster
• not rely on in inline bash manipulation on payload manifests

Acceptance Criteria:

Description of criteria:

• control-plane-operator calls CVO to bootstrap itself, instead of manipulating manifests through inline bash
• CVO bootstraps the exactly desired manifests based on annotations, as on standalone
• CVO bootstraps just the manifests necessary for CVO Deployment (still created dynamically by control-plane-operator

(optional) Out of Scope:

• Replacing the other hypershift-specific payload manipulation

Engineering Details:

• This card is a followup to OCPBUGS-44438 which I hope fill be fixed fast by a filename convention bandaid like https://github.com/openshift/hypershift/pull/5096 or https://github.com/openshift/hypershift/pull/5093
• This card depends on the CVO capability to bootstrap itself in HCP: OTA-1397
• There will likely need to be a period where both CVO bootstrapping methods are supported, because the new method will depend on the hosted cluster CVO having OTA-1397 code, but Hypershift will need to be able to install older versions as well
• HyperShift feature gate sounds like a good idea for this to allow proper stabilization of the change