Rolling Upgrades

[coreos]

Rolling Upgrades

[philips]

@betawaffle Do you have more thoughts on how we could do this? We need to carefully design this so we don't end in an etcd0 -> etcd2 situation.

Do we have version fields in all of the communication and on-disk stuff?

[betawaffle]

Part of this will be solved by the new protocol-in-the-url mechanism @barakmich has plans for. As for on-disk versions, hmmm. I think that's the main thing we need to consider.

[philips]

@betawaffle is there a concrete document describing that mechanism? We should probably start a Google doc as these things are very hard to get right.

[betawaffle]

Not yet. We should create one.

[barakmich]

This will actually be easier than that; a rolling upgrade is keeping track of the running (internal) versions, and we already have the nodes reporting into etcd. They could as easily report protocol versions, which can be handled with each client respecting each other client as the updates roll.

Solid project management will allow us to deprecate old versions; as long as we support one or two versions back, we can four-phase migrate the code, and this is equivalent to a rolling update.

Closing this bug in favor of a new one, proposing the addition of such a field in the PeerInfo proto