Followup to the Slack thread.

Right now HCP does not properly select CVO manifests to apply correctly based on FeatureSet, capability (are there other criteria?). Right now the behavior there is outright buggy (OCPBUGS-44438): HCP does not take FeatureSet into account at all, and simply applies everything in the release payload image's manifest/ directory (with some custom processing done through inline bash). I intend to fix OCPBUGS-44438 with a filename convention bandaid like https://github.com/openshift/hypershift/pull/5093 or https://github.com/openshift/hypershift/pull/5096 but cewong@redhat.com thinks we should teach Hypershift proper selection of the CVO manifests (based on annotations like on standalone) and I agree:

Cesar Wong Nov 11th at 20:56

I'm wondering what's the "right" way of fixing this. It doesn't feel like manipulating the manifests in a shell script is a good long term solution. My preference would be to add a command to the cvo to tell it to apply bootstrap manifests and pass a featuregate yaml

A reasonable proposal seems to be to implement a new CVO command that evaluates the desired properties (like featureset) and applies the correct subset of its manifests to the cluster. CVO would basically need to implement the basic manifest selection logic but add proper selection based on feature set, and then re-implement the CVO bootstrap logic.

HCP currently builds the actual CVO Deployment dynamically - replacing that logic is not in the scope of this card. HCP also filters the contents of the release payload release-manifests directory further. Replacing that logic is also not in the scope of this card.

Definition of Done

• Given a release image payload and a set of typical constraints (featureset, capabilities, are there more?), CVO is able to select the correct CVO manifests (from manifests/ directory contents) and bootstrap the hosted cluster with it, respecting the existing HCP bootstrap logic (it does not apply the CVO deployment and it does not apply the servicemonitors. It likely should not bootstrap further CVO image contents such as Update Status Controller manifests, just the CVO ones.