Documentation mismatch: What is the true default update strategy?

[acdoussan]

https://www.flatcar.org/docs/latest/setup/releases/update-strategies/#locksmithd-reboot-strategies states

The default behavior is reboot and results in a reboot with a delay of 5 minutes.

and further on in the page

If the applications running on your cluster are highly resilient, this strategy was made for you.

The readme in https://github.com/flatcar/locksmith states

The default strategy is to follow the etcd-lock strategy if etcd is running, and to otherwise follow the reboot strategy.

I'm still wrapping my head around k8s (assuming this is the primary use case and not single node docker hosts) so apologies if these questions are obvious. What is the true default? What does "if etcd is running" mean? Does this just mean if etcd is being used by the control nodes in the cluster? Or does this mean that if the specific node itself is running etcd?

Why would the reboot strategy be made for "highly resilient" applications? If reboot is the default, what is preventing 2 nodes in a 3 node cluster from rebooting at the same time, effectively bringing down the cluster and my applications? Assuming etcd is available, wouldn't having etcd-lock as the default make more sense to ensure high availability (as mentioned in the locksmith readme)?

[acdoussan]

Looking at the code it seems that the true default is the reboot strategy, unless something else manipulates the env variable before this is run.

https://github.com/flatcar/locksmith/blob/5b2275ec726a7f70902d2da0c782bbad405e3ef5/locksmithctl/daemon.go#L324

[pothos]

The locksmith etcd usage is a bit outdated and anyway not something you would use on Kubernetes because you need node draining. There is https://github.com/flatcar/flatcar-linux-update-operator and https://github.com/kubereboot/kured for that.