LWN: Comments on "Etcd and fleet"

ZooKeeper runtime reconfigurability

jaybuff — Thu, 13 Nov 2014 16:52:29 +0000

My understanding was that with ZK 3.5.0 it is possible to reconfigure during runtime. See https://issues.apache.org/jira/browse/ZOOKEEPER-107 and http://web.stanford.edu/class/cs347/reading/zab.pdf

Fixed

corbet — Tue, 04 Nov 2014 12:50:52 +0000

I have adjusted the text to reflect the actual origin of Raft. My apologies for my misunderstanding and any confusion it may have caused!

Etcd and fleet

philipsbd — Mon, 03 Nov 2014 23:17:15 +0000

Yea, I sent an email to the editor to get this fixed but it hasn't been fixed yet. A very complete resource is here: http://raftconsensus.github.io/

Etcd and fleet

sourcedelica — Mon, 03 Nov 2014 00:39:35 +0000

CoreOS came up with Raft? I thought Diego Ongaro came up with as part of the RAMCloud project. https://ramcloud.stanford.edu/raft.pdf

Etcd and fleet

philipsbd — Sun, 02 Nov 2014 01:20:01 +0000

Oh, there there are a number of great resources here: https://raftconsensus.github.io

Etcd and fleet

philipsbd — Sun, 02 Nov 2014 01:08:51 +0000

If you want a concrete implementation of raft check out the one we built for etcd[1]. It pairs quite nicely with the paper.

[1] https://github.com/coreos/etcd/tree/master/raft

Etcd and fleet

philipsbd — Sun, 02 Nov 2014 01:07:45 +0000

I want to clarify that CoreOS uses the same build system as Gentoo (portage) but a user of CoreOS will not know this. The CoreOS update mechanism is completely different[1], there is no emerge package manager on board and we ship very few user space tools relying on containers instead.

Please give it a shot. It is a quite different system than Gentoo. In fact the ChromeOS team basis their build system on Gentoo's portage too, but you would never know it.

[1] https://coreos.com/using-coreos/updates/

Etcd and fleet

raven667 — Tue, 28 Oct 2014 05:17:01 +0000

On sysvinit a tool like fleet would have to do all of its own service management, it would have to a parent of all the processes, manage cgroups, etc., in effect it would have to be systemd itself.

Etcd and fleet

kjp — Tue, 28 Oct 2014 02:38:47 +0000

a new consensus algorithm thats allegedly simpler than paxos? oh great, there goes my free reading time...

Etcd and fleet

anselm — Sat, 25 Oct 2014 23:42:42 +0000

In sysvinit, when you run your services from inittab, you give up the convenience of being able to start and stop them manually using “/etc/init.d/SCRIPT start” (or whatever). You also give up the ability to start them in a defined order so as to obey dependencies on other services. When you run your services by means of init scripts, you give up automatic restarts (and must add them again by means of piling on more hacks). This is an arbitrary and inconvenient dichotomy.

Systemd handles all services identically, whether they're automatically restarted or not. Dependencies and manual start/stop are available for all services. Exactly under what conditions a service is restarted, as well as rate-limiting for restarts, can be extensively configured. Systemd also supports “watchdog” functionality that can restart a service if the process appears to be running but hasn't shown signs of life for a specific time. In this respect systemd is in fact considerably superior to sysvinit.

Claiming that ”sysvinit does support restarting processes if they exit” is technically correct (under certain limited circumstances, anyway). Claiming that sysvinit does it as well as systemd, however, is ludicrous.

Etcd and fleet

dlang — Sat, 25 Oct 2014 21:01:24 +0000

"Is this service still running" is a rather complex question to answer, and it's far from clear that what an init system can do is sufficient.

There are lots of times when the process has not exited that the service is not healthy enough to function and failover is needed.

Sysvinit does support restarting processes if they exit, that's what inittab did. It did the job well and wasn't hard to manage (I had a server at one time with several hundred entries in inittab

Etcd and fleet

kleptog — Sat, 25 Oct 2014 20:55:40 +0000

Because to be able to have a stable system and to do things like failover you have to be able to answer the question "is this service still running?" and be able to receive a notification when a service dies. Sysvinit doesn't do that, it just starts services and forgets about them.

Things like daemontools are a step up, since it can at least tell when something dies, but it doesn't have the same kind of control.

Since unit files can also do things like job scheduling, you'd have to write something to distribute cron jobs as well.

You could probably attempt it with sysinit, but you'd get completely lost in the half-baked status scripts, inconsistent logging and other annoyances.

Etcd and fleet

dlang — Sat, 25 Oct 2014 19:14:53 +0000

why would something like fleet be impossible with sysvinit?

Etcd and fleet

kleptog — Sat, 25 Oct 2014 16:34:55 +0000

The last few years have been awesome in the Linux space. Docker bringing Linux containers to the masses. An extensible declarative system for describing services from systemd. And now the combination with stuff like etcd and fleet looks to completely change the way servers are set up and run.

Stuff like fleet would not have been possible with sysvinit, that's for sure.

I'm a little bummed by the fact that CoreOS is based on Gentoo though. Bad experiences.