Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make retry for clusterctl check for cert-manager API ready configurable #11960

Open
viveksyngh opened this issue Mar 12, 2025 · 1 comment
Open
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-priority Indicates an issue lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@viveksyngh
Copy link

viveksyngh commented Mar 12, 2025

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

We have some bits in the clusterctl init which checks for cert-manager API to be ready.

if err := cm.waitForAPIReady(ctx, false); err == nil {
log.Info("Skipping installing cert-manager as it is already installed")
return nil
}

The checks uses waitForAPIReady which is called without retry which means it just check for the API to be ready only once and if it is not ready then it installs a new cert-manger instance. We might have cert-manager already installed but may be experiencing some intermittent issue which can be avoided with retry.

// waitForAPIReady will attempt to create the cert-manager 'test assets' (i.e. a basic
// Issuer and Certificate).
// This ensures that the Kubernetes apiserver is ready to serve resources within the
// cert-manager API group.
// If retry is true, the createObj call will be retried if it fails. Otherwise, the
// 'create' operations will only be attempted once.
func (cm *certManagerClient) waitForAPIReady(ctx context.Context, retry bool) error {

Would like to add a flag (default to false) which can enable the retry of this particular check.

Detailed Description

Add a new flag in clusterctl init command to retry the check for cert-manager API readiness. This flag can have a default value to false which will keep the default behaviour but can be overridden.

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 k8s-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. needs-priority Indicates an issue lacks a `priority/foo` label and requires one. labels Mar 12, 2025
@k8s-ci-robot
Copy link
Contributor

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.

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.

@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Mar 12, 2025
@viveksyngh viveksyngh changed the title Make retry for clusterctl check for cert-manager API ready configurable Make retry for clusterctl check for cert-manager API ready configurable Mar 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-priority Indicates an issue lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants