v1alpha4: write sentinel file as part of bootstrap

[CecileRobertMichon]

original discussion: https://kubernetes.slack.com/archives/C8TSNPY4T/p1599744069010700
/cc @jdef

See also:
kubernetes-sigs/cluster-api-provider-azure#603
proposal: https://docs.google.com/document/d/1U0GxvO6ltgIINMjpQz96UD4bExlN2h21wyyn-3ENezc/edit
https://docs.google.com/document/d/1FVRxo9toKSUmvKIUFFzPFhnFrfdR9s7S6Bl4shovNlg/edit#heading=h.3mwmvwsf4jyi
Sept 16 2020 office hours

Proposal: change the bootstrap provider contract to include writing a sentinel file at a specific (or possibly user-configurable?) location. For example, for CABPK, this would look like adding a touch $filepath echo success > filepath (to be compatible with Windows) after the kubeadm init or join command in the script that is written as Boostrap Data.

This would not completely solve the problem of bootstrap failure detection but provides a clear signal to the infra provider that bootstrap is complete and the infrastructure provider can then take it from there and use infra specific mechanisms to read that signal.

/kind feature
/kind proposal
/milestone v0.4.0

[jdef]

For example, for CABPK, this would look like adding a touch $filepath after the kubeadm init or join command in the script that is written as Boostrap Data.

Should this be clarified? e.g. only touch the sentinel file once the kubeadm init or kubeadm join command has completed successfully.

User-configurability isn't very important for my use case. That said, CAPBK already makes assumptions about writing to /tmp, right? It would be nice if the contract here didn't make any assumptions about filesystem existence other than what is already assumed.

[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

[fabriziopandini]

/remove-lifecycle stale

[CecileRobertMichon]

/assign

[fabriziopandini]

background question: does this a problem falls into the node agent responsibility? cc @randomvariable

[vincepri]

It should probably be a contract respected in all bootstrap providers

[CecileRobertMichon]

Yes, it's up to each bootstrap provider to determine what counts as "successful" bootstrapping. For example, for CABPK it would be if kubeadm init or kubeadm join exits 0. It's up to each bootstrap provider to get the file on the VM according to its own implementation.

The presence of the file itself is what should be part of the contract.

[fabriziopandini]

Ok thanks!
I'm looking forward to the node agent design doc to get all the pieces together and understand if/how this will impact bootstrap providers as well

[randomvariable]

I know we don't have a label for it, but just for tracking

/area node-agent

[k8s-ci-robot]

@randomvariable: The label(s) area/node-agent cannot be applied, because the repository doesn't have them

In response to this:

I know we don't have a label for it, but just for tracking

/area node-agent

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.