Immediate need: etcd is moving too fast to version the internal API right now. But, we need to keep mixed version clusters from being started by a rolling upgrade process (e.g. the CoreOS developer alpha).

Longer term need: Having a mixed version cluster where all peers are not running the exact same version of etcd itself but are able to speak one version of the internal protocol.

Solution: The internal protocol needs to be versioned just as the client protocol is. Initially during the 0.*.* series of etcd releases we won’t allow mixed versions at all.

If the leader controls the version of followers joining the cluster then it compares its version to the version number presented by the follower in the JoinCommand and rejects the join if the number is less than the leader’s version number.

Advantages

• Leader controls all cluster decisions still

Disadvantages

Follower Controlled

Advantages

• The follower is running newer code and knows better if it can talk older protocols

Disadvantages

• This cluster decision isn’t made by the leader

To solve the immediate need and to plan for the future lets do the following:

• Add Version field to JoinCommand

Research

doozerd stores the version number of the peers in the datastore for other clients to check, no decisions are made off of this number currently.