Giters

kubernetes-sigs / cluster-api

Home for Cluster API, a subproject of sig-cluster-lifecycle

Home Page:https://cluster-api.sigs.k8s.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Deprecate KCP.Available condition

fabriziopandini opened this issue · comments

commented

What would you like to be added (User Story)?

As a user I would like clear observability signals.

Detailed Description

As per #3779 discussion:

WRT to Initialized vs Available:

  • As of today Cluster.ControlPlaneInitialized is used everywhere.
  • Cluster.ControlPlaneInitialized derives from ControlPlane.status.initialized, and it is up to the control plane provider to determine when to set it to true (KCP currently assumes the control plane is initialized when there is a kubeadm-config map in the workload cluster, and this imply that there is a working LB and API server for the workload cluster).
  • Available condition exists only in KCP, and it has the very same meaning of KCP.status.initialized

Considered that IMO the most practical way forwards is

  • To close this issue because we don't need to change the contract, ControlPlane.status.initialized is already documented
  • To open a new issue to drop KCP.Available, or to replace it with KCP.Initialized to get rid of the less used noun

This issue is about the last point.
My preference goes to introduce a KCP.Initialized condition (that mirrors ControlPlane.status.initialized)

Anything else you would like to add?

No response

Label(s) to be applied

/kind cleanup
/kind api-change
/area control-plane
/priority important-longterm

commented

This issue is currently awaiting triage.

CAPI contributors will take a look as soon as possible, apply one of the triage/* labels and provide further guidance.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

commented

I guess we can already work on deprecating the current Available condition and adding the new one? (then we only have to drop the old one with the next apiVersion, otherwise we then have to wait another apiVersion)

(just mentioning this because we were often ~ interpreting "api-change" as "this has to wait until we cut the new apiversion" in a lot of cases, and it's not true, we actually have to do something before)

commented

I guess we can already work on deprecating the current Available condition and adding the new one?

That's correct