kubernetes-sigs/cluster-api

Make retry for `clusterctl` check for cert-manager API ready configurable

Open

#11,960 opened on Mar 12, 2025

View on GitHub
 (3 comments) (1 reaction) (1 assignee)Go (1,532 forks)auto 404
help wantedkind/featurepriority/backlogtriage/accepted

Repository metrics

Stars
 (4,267 stars)
PR merge metrics
 (PR metrics pending)

Description

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.

https://github.com/kubernetes-sigs/cluster-api/blob/ccaea78cdbf068a1fe072bde78794e98c15c1072/cmd/clusterctl/client/cluster/cert_manager.go#L162-L165

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.

https://github.com/kubernetes-sigs/cluster-api/blob/ccaea78cdbf068a1fe072bde78794e98c15c1072/cmd/clusterctl/client/cluster/cert_manager.go#L540-L546

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.

Contributor guide

Research direction
Implement a new boolean flag in `clusterctl init` to enable retry logic for cert manager API readiness check. Add the flag to the command struct, parse it, and modify `waitForAPIReady` calls to retry when the flag is set. Ensure backward compatibility by defaulting to false.
Tech stack
go
Domain
cli
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
Go
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
65