Over time, Cluster API are evolving their API contracts. We need to be able to, during the Technology Preview and beyond, lifecycle these APIs and ensure that we do not break consumers.

Some of this is handled automatically by clusterctl normally, but we will need to operator on this ourselves.

Things that need to be understood:

• Who is responsible for installing CAPI related CRDs (CVO, CCAPIO, other?)
  • How will installation be managed
• When an API version is changed, how do we handle the upgrade process
  • What are the requirements for storage versions and the migration
  • How do we trigger a storage version migration
  • Can we deprecate older versions of APIs in upstream projects, eg remove v1alpha3 after some period of v1alpha4 support
• How will other components interact, eg, HyperShift, which relies on CAPI APIs
• How do we communicate/co-ordinate API version changes externally/internally
• How will we lifecycle/maintain conversion webhooks for CAPI resources
• What are the time frames for upstream components upgrading to new API versions, what impact might this have on our release processes?
• What is the schedule for providers to update to newer versions, how do we ensure compatibility

The output of this spike is an enhancement that can be reviewed by API approvers within OpenShift and relevant other stakeholders (eg HyperShift, Hive, SD)

Outcome:

• Write up an enhancement describing how CAPI CRDs will be lifecycled
• Ensure documentation is written for how to handle an API version change within CAPI and the caveats that we need to be aware of when doing this