🐛 make manifest to use cert-manager.io/v1alpha2

[fabriziopandini]

What this PR does / why we need it:
#4225 made clustectl to deploy cert manager v1.1.0. and updated manifests generation in order to generate Certificate objects using cert-manager.io/v1 apiVersion.

Unfortunately this is creating a problem for people using old versions of clusterctl for doing clusterctl init because e.g.:

• clusterctl init with clusterctl v0.3.14 installs cert manager v0.16.1
• clusterctl init then installs the latest version of providers, that now is v0.3.15 which creates cert-manager.io/v1 objects.

This makes init to fail with older version of clusterctl.

This PR fixes this problem by changing our manifests in order to generate Certificate objects using cert-manager.io/v1alpha2 apiVersion, which can be processed either by v0.16.1 and v1.1.0 version of cert manager

Note
As a temporary workaround it is possible to pin version of the installed providers

clusterctl init \
	--core cluster-api:v0.3.14 \
	--bootstrap kubeadm:v0.3.14 \
	--control-plane kubeadm:v0.3.14 \
	--infrastructure vsphere:v0.3.14

[CecileRobertMichon]

I see this PR is targeting release-0.3, is the plan to keep cert-manager.io/v1 in 0.4?

[fabriziopandini]

I see this PR is targeting release-0.3, is the plan to keep cert-manager.io/v1 in 0.4?

given that it is required to use clusterctl v0.4.0 to create v1alpha4 clusters, it is fine to keep cert-manager.io/v1 in 0.4.
the problem is only on the v0.3 branch because people can use old version of clusterctl to create clusters with CAPI >= 0.3.15

[sbueringer]

/lgtm
seems reasonable to me

[detiber]

/approve
/hold
hold for @CecileRobertMichon to have a chance to see if the response was sufficient.

[vincepri]

Given that the other PR was marked as ⚠️, should we downgrade here, or force the use of the newer clusterctl version instead?

IIRC, clusterctl should check if there is a new version of the CLI available, is that not the case?

I'd mostly like to understand if we need to keep full compatibility between the manifests going forward, I'm ok either way.

[fabriziopandini]

I think we should aim to full compatibility between the manifests going forward (within a minor), and in this case this can be achieved with a small change.
While we are alpha, I guess we can break this promise if necessary e.g. due to security patches, but in that case we should make a better job in informing users...

[vincepri]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: detiber, vincepri

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [detiber,vincepri]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[CecileRobertMichon]

/lgtm
/hold cancel