kubernetes-sigs / kubernetes-sigs/cluster-api-provider-openstack

OpenStackMachine controller does not requeue when bootstrap data secret is not yet available

Open Beginner friendly
#3,228 4 comments 0 reactions 0 assignees View on GitHub
kind/bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.