Repository navigation
cluster-api: bump cluster-api-operator past v0.19 and drop the --sync-period patch #5037
Description
What is wrong?
capi-operator is on chart ^0.19 (operator v0.19.0). Its health check reconciler ignores create events of provider Deployments, so after an operator restart provider conditions stay stale until the first resync, about 20 minutes with default period (kubernetes-sigs/cluster-api-operator#1031, see #4926). #4939 works around it with --sync-period=1m and a patch to the vendored chart.
Fix is upstream in kubernetes-sigs/cluster-api-operator#1032, first release with it is v0.27.0 (v0.30.0 is the latest now).
How it should work?
Bump the chart to a release with that fix and drop the workaround from #4939: patches/sync-period.diff, the syncPeriod value and hack/capi-operator_test.bats.
Things to check before the bump, I did not try it:
- v0.20.0 removed the deprecated v1alpha1 API. Providers in this repo use
operator.cluster.x-k8s.io/v1alpha2everywhere, so it should be fine - v0.25.0 and v0.29.0 move supported CAPI to 1.12 and 1.13.5, and we pin core
v1.10.1incapi-providers-core. Need to see if newer operator still installs the pinned providers or they should be bumped together
Reacted by dosubot
Reacted by Marian Koreniuk
Activity
themoriarti commentedon Oct 22, 2026
#4902 already moves cluster-api-operator to v0.29.0, together with core and kubeadm v1.13.7, so the operator bump from this issue lands with it. It also covers the two open points: every provider here is on
operator.cluster.x-k8s.io/v1alpha2, and the operator and core move in one step, so operator v0.29 never runs against the pinned core v1.10.1.#4902 still merges cleanly into main after #4939, but the merged tree keeps
patches/sync-period.diff,syncPeriod: 1mandhack/capi-operator_test.batson top of the v0.29 chart. So once #4902 is in, what is left here is dropping those three, either in #4902 itself or as a small follow-up.