The discovery mechanism looks clumsy to me.<p>There's no way we'd rely on a public discovery service, for example. If we're going to hardcode configuration information - such as the URL of a discovery service that may or may not be up or reachable, we might as well hardcode the addresses of a few peers.<p>And running a second etcd cluster to bring up the main one seems pointless. Either it's turtles all the way down, or you then need to hardcode config information for the second cluster, in which case it serves little purpose.<p>I'd rather have a mechanism where each peer takes a list of possible peers and tries to connect, with a method for deciding when there is quorum to elect an initial leader and start allowing writes (that's easy enough by introducing a config option to decide if a peer is "blessed" to be part of the initial leadership election, and how many blessed peers must be connected to have quorum - just needs to be enough to form a majority of blessed peers to prevent more than one subset from electing a leader before they manage to connect)<p>Am I missing something?