cluster-api: Mismatch between ControlPlaneReady and Conditions.ControlPlaneReady
What steps did you take and what happened:
Running CAPD with tilt from HEAD, created a new runtime extension webhoook server and added the function hook for ControlPlaneInitialized, I wanted to execute a few steps AFTER the Cluster being ready, first try was to read from request.Cluster.Status.ControlPlaneReady boolean to check if I can create my pod in the WL cluster. This operations never happened even if the condition of Type ControlPlaneReady is True eventually.
E0820 17:11:02.074289 18 handlers.go:75] "Control plane not ready retrying."
phase Provisioned
controlplaneready false
infraready true
Ready False
// conditions
ControlPlaneInitialized True
ControlPlaneReady False
InfrastructureReady True
... repeats 8x
I0820 17:11:06.312747 18 handlers.go:55] "AfterControlPlaneInitialized is called."
E0820 17:11:06.312803 18 handlers.go:75] "Control plane not ready retrying."
phase Provisioned
controlplaneready false
infraready true
// conditions
Ready True
ControlPlaneInitialized True
ControlPlaneReady True
InfrastructureReady True
I0820 17:11:06.344126 18 handlers.go:55] "AfterControlPlaneInitialized is called."
In the last line request.Cluster.ControlPlaneReady == false, and all Conditions are true, as noted this does not happen to the InfrastructureReady.
Can this be for the fact I’m returning an ReponseStatusFailure while waiting for the cp be ready?
What did you expect to happen: To both fields be in sync when the cp is ready.
Environment:
- Cluster-api version: HEAD
- minikube/kind version: 0.14.0
- Kubernetes version: (use
kubectl version): 1.24 - OS (e.g. from
/etc/os-release): Debian (WSL)
/kind bug [One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 23 (21 by maintainers)
That said - I think it’s probably a good idea to move the setting of
status.ControlPlaneReadyto the same place as the condition is set so there’s no difference between these fields.I’m not sure if CRD columns support the full jsonPath. It’s probably also not a good idea to depend on a certain condition being the first one in the array (not sure if more dynamic array element matching is supported by CRD columns). I had some problems with CRD columns in the past.
IIRC the plan was to migrate eventually to conditions. I’m not sure if we wanted to drop the bools accordingly.
After doing a little bit of testing here there is a significant drift between the two markers depending on network configuration:
The condition
ControlPlaneReadyis based on whether or not the ControlPlane machines and components are created and ready.Cluster
.status.controlPlaneReady, is a summary of whether or not the Nodes are in a ready state. It will never become true until the CNI is in place in practice. i.e.NetworkReadyfor the node object must be true.I’m not sure of the different networking constraints for different providers, but I can imagine a situation where no CNI means limited API server access.
We might want to align these values (or possibly deprecate the old status fields). I’m not read into the full context here, but is there any reason to keep the status ‘Ready’ fields around (vs conditions) in the long term? i.e. apart from backward compatibility etc.
We could deprecate without an intention to remove until the next API revision to signal that the condition is the better value to rely on.