bugs
bugs copied to clipboard
coreos
locksmithctl always assumes etcd is being used
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.
Now that I'm a maintainer, I guess I should. I've been tricked.
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.
@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.
