bugs
bugs copied to clipboard
locksmithctl always assumes etcd is being used
Issue by crawford
Wednesday Jan 21, 2015 at 01:30 GMT
Originally opened as https://github.com/coreos/locksmith/issues/60
On a system without etcd running, using the "best-effort" or "reboot" reboot strategy, locksmithctl reboot
results in:
Error initializing etcd client: 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]
If etcd is not being used, locksmithctl reboot
should just reboot the system.
Comment by crawford
Thursday Jan 22, 2015 at 17:54 GMT
Now that I'm a maintainer, I guess I should. I've been tricked.
Comment by mattbostock
Sunday Feb 01, 2015 at 10:52 GMT
Would it not be safe to assume that someone using locksmithctl
is fully expecting that etcd is used? In other words, if you know etcd
is not running, should you not just use reboot
?
I think it would be surprising to users that locksmithctl reboot
reboots the machine if etcd is unavailable. I could also forsee circumstances where etcd should be running but is down, and this behaviour would cause the machine to reboot unexpectedly.
Comment by jonboulle
Sunday Feb 01, 2015 at 12:05 GMT
@mattbostock I had the same reaction initially on reading this ticket, but actually this is much more specifically only when someone has explicitly disabled locksmith. In this case, it makes sense for locksmithctl to ignore etcd. On Feb 1, 2015 11:52 AM, "Matt Bostock" [email protected] wrote:
Would it not be safe to assume that someone using locksmithctl is fully expecting that etcd is used? In other words, if you know etcd is not running, should you not just use reboot?
I think it would be surprising to users that locksmithctl reboot reboots the machine if etcd is unavailable. I could also forsee circumstances where etcd should be running but is down, and this behaviour would cause the machine to reboot unexpectedly.
— Reply to this email directly or view it on GitHub https://github.com/coreos/locksmith/issues/60#issuecomment-72360053.
Following the title of this issue, it would be great if locksmithctl called out to a separate tool, and rebooted iff that tool exited 0 (for example). I'd like to use zookeeper instead of etcd (I'm using mesos), and currently my only option to add a new strategy is to reimplement the entire locksmith machinery.
(If following this proposal, it should probably be specified whether the tool should block or fail-fast if waiting for a network lock service, etc)
Seems like this is still relevant.
Our use case does not need etcd or the need to configure it, but we would like to use the system to handle updates and reboot.
This is on 1520.8.0.
@tonglil As of Container Linux 1535.0.0, locksmithd defaults to performing an uncoordinated reboot after an update, which should handle your use case. locksmithctl reboot
still assumes etcd, which is the subject of this bug, but that command is primarily useful for coordinating a manual reboot performed for other reasons (e.g. system maintenance). Since you don't need that functionality, you can just use systemctl reboot
when you need to do a manual reboot.
Thanks @bgilbert!