User Story

• As an OpenShift engineer I want to reduce the complexity of the CAPI component installation process so that it is more easily developed and maintainable.
• As an OpenShift engineer I want a way to install CAPI providers depending on the platform the cluster is running on

Background

In order to reduce the complexity in the system we are proposing to get rid of the upstream cluster-api operator (kubernetes-sigs/cluster-api-operator). We plan to replace the responsibility of this component, which at the moment is responsible for reading, fetching and installing the desired providers in cluster, by implementing them directly in the downstream openshift/cluster-capi-operator.

Steps

• Removal of the upstream cluster-api-operator manifest/CRs generation steps from the asset/manifest generator in (https://github.com/openshift/cluster-capi-operator/tree/main/hack/assets), as this component is removed from the system
• Removal of the Cluster Operator controller (which at the moment loads and applies cluster-api-operator CRs)
• Introduction of a new controller within the downstream cluster-capi-operator, called CAPI Installer controller, which is going to be responsible for replacing the duties previously carried out by the Cluster Operator controller + cluster-api-operator, in the following way:
  • detection of the current Infrastructure platform the cluster is running on
  • loading of the desired CAPI provider manifests at runtime by fetching the relevant transport ConfigMaps (the core and the infrastructure specific one) containing them (there can be multiple CMs per each provider, use label selectors for fetching them, see here).
  • extraction of the CAPI provider manifests (CRDs, RBACs, Deployments, Webhooks, Services, ...) from the fetched transport ConfigMaps
  • injection of the templated values in such manifests (e.g. ART container images references)
  • order aware direct apply of the resulting CAPI providers manifests at runtime (using library-go specific pkgs to apply them where possible)
  • continuous tracking of the provider ConfigMaps and reconciliation of the applied CAPI components
• Left to do:
  • Rebase changes
  • Some boilerplate about creating a new controller
  • Apply deployments/daemonsets in a simple way
  • Apply correct environment variables to manifests

Stakeholders

• Cluster Infrastructure team
• ShiftStack team
• Hypeshift team

Definition of Done

• Currently CAPI E2E tests should still pass after this refactor

• Improved Docs
• Improved Testing