Allow retry to happen during EnsureInstalled(...) for initial cert-manager installation verification

[troy0820]

What would you like to be added (User Story)?

During clusterctl init, we look to create some test cert-manager resources to see if cert-manager is installed. Say for instance you are installing cert-manager yourself to manage and have a job that runs clusterctl simultaneously, clusterctl will install cert-manager if it finishes before the managed cert-manager install (webhook, cainjector, etc).

In the method EnsureInstalled, we call waitForAPIReady to then create a cert-manager deployment disallowing the user to add a retry when initially trying to see if it can install the test objects.

Detailed Description

Proposal:

1. Allow the user to apply retry with a flag to extend the functionality of clusterctl init to be passed to EnsureInstalled()
2. Allow that flag to take into consideration the configuration of clusterctl itself
3. Use the configuration timeout (or the default timeout) to then create the cert-manager installation

Anything else you would like to add?

No response

Label(s) to be applied

/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[troy0820]

/area clusterctl

[fabriziopandini]

(from clusterctl docs)

While doing init, clusterctl checks if there is a version of cert-manager already installed. If not, clusterctl will install a default version (currently cert-manager v1.20.1).

IMO clusterctl is behaving as expected.
Looking at this from another angle, I don't think that clusterctl should be responsible to account for orchestration with the external system that it is installing cert-manager.

[troy0820]

I don't disagree with this; however we are already making assumptions when we initiate the clusterctl command. We insist that the cert-manager installation if not installed before that command is invoked, that cert-manager is not installed and we will install it.

I agree that clusterctl should not be responsible for taking into account the orchestration of self-managed cert-manager and what clusterctl looks for, but allowing the person using the command to set the parameters around its self-managed cert-manager installation.

The timeout parameter for the configuration of cert-manager (defaulted to 10 minutes) can be configured if it takes too long to install cert-manager.

I am not looking for footgun that can potentially ruin this experience, but simply something that would wait before making the assumption that cert-manager is not installed before creating the installation itself.

Allowing this customization can potentially limit the work that has to be performed when using clusterctl init