Upgrade CAPI to v1alpha4 & CAPM3 to v1alpha5 for Bare Metal

[eak13]

Once it is been released for GA, upgrade CAPI components from v0.3.x to v0.4.x (aka v1alpha4). There will also be a need to uplift a corresponding version of CAPM3 from v0.4.2 to v0.5.0 (aka v1alpha5) at the same time.

When upgrading, the following need to be taken into consideration:

• Are there breaking changes that require coding/configuration changes for the CAPI components?
• Are there bug fixes in the upgrades that fix issues encountered when deploying? If so, are there workarounds in place today that would need to be removed or deprecated? May need input from @sb464f and others who have been running deployments.
• Are there any new features in the upgrades that address missing capabilities which have hindered the deployments? In utilizing these new features, what workarounds are in place today that would need to be removed or deprecated? May need input from @sb464f and others who have been running deployments.

Sources
Cluster API

• https://cluster-api.sigs.k8s.io/developer/providers/v1alpha3-to-v1alpha4.html
• https://github.com/kubernetes-sigs/cluster-api

CAPM3

• https://github.com/metal3-io/cluster-api-provider-metal3

The goal of this issue is to upgrade the CAPI & CAPM3 components, but leave current functionality in place as much as possible. If there are new features in the upgrade that Airshipctl can take advantage of, these should be reviewed on the Design Call & new issues created to implement. This should occur after the CAPM3, BMO & Ironic upgrades being performed in #554

[Arvinderpal]

Here are my notes from the PTG on upgrading. Please let me know if further info is needed.

Upgrade to v0.4 (aka v1alpha4)

Upgrading CAPI and Provider Components (e.g. v0.3.16 --> v0.4.0)

The clusterctl upgrade command can be used to upgrade the version of the Cluster API providers (CRDs, controllers) installed into a management cluster. See CAPI upgrade docs.

Upgrading API object (e.g. v1alpha3 --> v1alpha4)

clusterctl does not upgrade Cluster API objects (Clusters, MachineDeployments, Machine etc.); upgrading such objects are the responsibility of the provider’s controllers.
Controllers like CAPM3 have conversion functions built in, so conversion should be seamless.

Clusterctl Library

airshipctl consumes clusterctl as a library. As of Apirl, 16th, we are importing v0.3.13.

• Unless we plan to adopt the CAPI Provider Operator (Proposal Doc), airshipctl code changes should be minimal with respect to clusterctl.

K Version Upgrades

• CAPI / KCP v1alpha4 won't be able to manage Kubernetes clusters < v1.18
• In general, supported versions will be limited. See thread here.
• Requirement comes primarly through dependence on kubeadm. Currently kubeadm bootstrapper imports kubeadm API types.
• CAPI/kubeadm do not handle users API objects (e.g. Deployments, ConfigMaps, etc). For example, if an API is depreciated, the user must either use kubectl or helm to update their manifests.