Add a field on Cluster Status indicating the control plane is ready

[chuckha]

/kind feature

Describe the solution you'd like
CAPI uses an annotation to mark a cluster with a control plane ready for joining new nodes. Instead of using an annotation we should use a field on Status.

Anything else you would like to add:
See kubernetes-retired/cluster-api-bootstrap-provider-kubeadm#99

/cc @detiber @fabriziopandini @ykakarap

[ykakarap]

Since this is related to an issue I am working on in CABPK (#99), I would like to take this up.

/assign @ykakarap

[vincepri]

@chuckha I don't think CAPI uses any annotations today to mark a control plane ready, were you referring to CAPA?

@ykakarap Before starting implementing Status.ControlPlaneReady field, we should first update the cluster proposal document to reflect this change and include details such as: how will we determine if a Cluster's control plane is ready, how can we make sure we can re-calculate readiness given that the value is going to be in Status.

[chuckha]

@vincepri https://github.com/kubernetes-sigs/cluster-api/blob/master/pkg/controller/machine/machine_controller_phases.go#L279

is what I'm referencing

[vincepri]

Things past me wrote and I forgot 😂

[moshloop]

This will need to consider #1197 and #1250 which could potentially influence this.

[vincepri]

/cc @ncdc

[ncdc]

I am in favor of making this change. We have it as an annotation in v1alpha1, mainly because we didn't want to modify the API. I think it makes sense to promote this to a regular field for v1alpha2 so it is more visible.

As far as #1197 and #1250, there is not time for either of those to land in v1alpha2, so (pending lazy consensus) this should be able to go in by itself.

[ykakarap]

I am guessing we only want to add the field for now and considering refactoring the code to use this field instead of the annotation in a follow-up issue, correct?

[ncdc]

I'd rather do it in a single PR. But we should open a PR to modify the proposal first.

I'd actually like to propose we consider naming it ControlPlaneInitialized instead of ControlPlaneReady. I don't think we necessarily need to constantly monitor the health of the control plane and update this bool. I'd rather use it as a gate that only ever changes from false to true a single time.