kubernetes-sigs / kubernetes-sigs/cluster-api-provider-openstack
OpenStackMachine controller does not requeue when bootstrap data secret is not yet available
- Dominant language
- Go
- Stars
- 369
- Forks
- 315
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 33
Description
/kind bug
**What steps did you take and what happened:**
1. Parallel apply of 50–100 ClusterDeployments on host cluster.
2. Reviewed CAPO source. In controllers/openstackmachine_controller.go (~line 377), when Machine.Spec.Bootstrap.DataSecretName is nil, OpenStackMachineReconciler logs "Bootstrap data secret reference is not yet available", sets InstanceReady=False / WaitingForBootstrapData, and returns ctrl.Result{}, nil with no RequeueAfter:
if machine.Spec.Bootstrap.DataSecretName == nil {
scope.Logger().Info("Bootstrap data secret reference is not yet available")
conditions.Set(openStackMachine, metav1.Condition{
Type: infrav1.InstanceReadyCondition,
Status: metav1.ConditionFalse,
Reason: infrav1.WaitingForBootstrapDataReason,
})
return ctrl.Result{}, nil // no RequeueAfter
}
3. Under parallel load (50–100 hosted clusters, kube-api qps/burst 40/60 on host, the CAPI Machine controller is backlogged. Bootstrap propagation is: (1) bootstrap controller sets KubeadmConfig.Status.DataSecretName, (2) CAPI Machine controller copies to Machine.Spec.Bootstrap.DataSecretName, (3) CAPO reads Machine.Spec.Bootstrap.DataSecretName. If CAPO reconciles between steps 1 and 2, it exits without scheduling another reconcile.
4. The same file already requeues correctly when waiting for cluster infrastructure readiness (~line 373, RequeueAfter: waitForClusterInfrastructureReadyDuration). The bootstrap-data wait does not.
5. The no-requeue pattern is present in source and is a plausible stuck-machine failure under concurrent Machine creation; manual reconcile of a stuck OpenStackMachine would be the expected workaround if hit.
**What did you expect to happen:**
While Machine.Spec.Bootstrap.DataSecretName is unset, the controller should periodically requeue using the existing constant waitForClusterInfrastructureReadyDuration (15 * time.Second, line 69) and retry until the field is populated — consistent with the cluster-infrastructure wait in the same reconciler.
Suggested fix:
return ctrl.Result{RequeueAfter: waitForClusterInfrastructureReadyDuration}, nil
**Anything else you would like to add:**
- Bootstrap/control-plane: CAPI core v1.11.2
- If bootstrap is permanently misconfigured, indefinite requeue with WaitingForBootstrapData visible is preferable to silently stopping after one attempt (same rationale as cluster-infrastructure wait at line 373).
**Environment:**
- Cluster-API version: v1.11.2
- OS (e.g. from /etc/os-release): Ubuntu 24.04.3 LTS (Noble Numbat)
Contributor guide
Research direction
Start in controllers/openstackmachine_controller.go around the bootstrap-data check near line 377, and compare it with the cluster-infrastructure wait near line 373 and the waitForClusterInfrastructureReadyDuration constant near line 69. Confirm the missing bootstrap reference schedules the same periodic retry, then run the controller tests and verify reconciliation continues until Machine.Spec.Bootstrap.DataSecretName is populated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cloud, infrastructure
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100