Update clusterctl create when machines objects have a provisioning indication

[jessicaochen]

Seeing a node in the machine status cannot be purely relied upon because the provisioned master may not be registering with the stack that provisions it.

[davidewatson]

Currently clusterctl requires an annotation set by the provider to determine when nodes have been created.

Annotations are usually used to extend the spec, and conditions are can be used to extend the status. If #483 is merged then maybe the required annotation which is used for this now should be replaced by a condition.

Note that there would still be one place where an annotation is optionally used by the core controller code:

cluster-api/pkg/controller/machine/node.go

Line 53 in 051f338

val, ok := node.ObjectMeta.Annotations[machineAnnotationKey]

[davidewatson]

I originally thought it would be possible to reuse the Node condition KubeletReady to indicate a Machine had been created, but now I am not so sure. One problem is this coupling is not trivial when the corresponding Machine is in a different cluster than the Node.

When we were working on our ssh provisioner, we had to ssh from the manager cluster (where our controllers run) to the managed master in order to generate the kubeadm token. This was only necessary when we did not pivot. I think individual providers will have to do something similar if they choose to allow Cluster API resources to exist outside of the cluster they manage.

Will have to think more about this.

[davidewatson]

Propose we leave this as is for v1alpha1.

[vincepri]

/milestone Next

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[vincepri]

/remove-lifecycle stale

[ncdc]

I'm not entirely clear on what this issue is about. Could someone please clarify? Thank you!

[davidewatson]

A Ready "status" is only one of the states we need to expose for Bootstrapping. Therefore we'll close this issue and handle the general problem within the context of Bootstrapping.

/close

[k8s-ci-robot]

@davidewatson: Closing this issue.

In response to this:

A Ready "status" is only one of the states we need to expose for Bootstrapping. Therefore we'll close this and handle this there.

/close

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.