Closed prometherion closed 9 months ago
Why don't you let the defer function update not only the condition but also the status of kamaji control plane(KCP)?
I think both ready Condition and ready Status should be updated at the same time.
Is there a reason for calling the updateKamajiControlPlaneStatus receiver inside the TrackConditionType function instead of letting the defer function update the status of the kamaji control plane(KCP)?
# REDACTED
status:
conditions:
- lastTransitionTime: "2023-12-11T16:59:14Z"
message: ""
observedGeneration: 1
reason: Succeeded
status: "True"
type: TenantControlPlaneCreated
- lastTransitionTime: "2023-12-11T16:59:14Z"
message: ""
observedGeneration: 1
reason: Succeeded
status: "True"
type: TenantcontrolPlaneAddressReady
- lastTransitionTime: "2023-12-11T16:59:14Z"
message: ""
observedGeneration: 1
reason: Succeeded
status: "True"
type: InfrastructureClusterPatched
- lastTransitionTime: "2023-12-11T16:59:14Z"
message: ""
observedGeneration: 1
reason: Succeeded
status: "True"
type: KamajiControlPlaneIsInitialized
- lastTransitionTime: "2023-12-11T16:59:16Z"
message: ""
observedGeneration: 1
reason: Succeeded
status: "True"
type: KubeadmResourcesCreated
- lastTransitionTime: "2023-12-11T16:59:16Z"
message: TenantControlPlane in Provisioning status, enqueue back
observedGeneration: 1
reason: Failed
status: "False" # ready Condition and ready Status should be updated at the same time.
type: KamajiControlPlaneIsReady
externalManagedControlPlane: true
initialized: true
ready: true # ready Condition and ready Status should be updated at the same time.
readyReplicas: 2
replicas: 2
selector: cluster.x-k8s.io/cluster-name=capi-quickstart
unavailableReplicas: 0
updatedReplicas: 2
version: v1.23.10
Ready is unbounded from the required resources such as the CA and the Kubeconfig, I could have the secret resources created but the TCP not yet ready.
We're tricked by the fact Kamaji is extremely fast, in other circumstances it could tale time and we wait for the API Servers from being up and ready.
Ready is unbounded from the required resources such as the CA and the Kubeconfig, I could have the secret resources created but the TCP not yet ready.
We're tricked by the fact Kamaji is extremely fast, in other circumstances it could tale time and we wait for the API Servers from being up and ready.
Wouldn’t this comment be confusing?
type KamajiControlPlaneStatus struct {
// The TenantControlPlane API Server is ready to receive requests.
Ready bool `json:"ready"`
@jds9090 that ready
field is reported by Kamaji itself. From a Kamaji standpoint, if the Pods are up and running, it means the API Server is ready to receive requests, as well as the Control Plane from the CAPI domain.
Of course, if the network is not well configured, it would be out of the scope since we cannot check variables outside of our control, such as a not yet announced IP, NetworkPolicies, etc.
@jds9090 that
ready
field is reported by Kamaji itself. From a Kamaji standpoint, if the Pods are up and running, it means the API Server is ready to receive requests, as well as the Control Plane from the CAPI domain.Of course, if the network is not well configured, it would be out of the scope since we cannot check variables outside of our control, such as a not yet announced IP, NetworkPolicies, etc.
Even when KCP(Kamaji Control Plane) is in ready state, Tenant control plane can be not ready to communicate.
That's why I think the comment is confusing.
My suggestion is as below //Kamaji control plane is ready to link CAPI with tenant control plane.
I accept the suggestion, thanks! 🤗
Closes #66.
@jds9090 I tried to summarize the state transitions in the following YAML, let me know what do you think.