On Mon, Jan 11, 2010 at 12:03 PM, Ryan King <r...@twitter.com> wrote: > Both of the above are fine. I think we could even tolerate having to > run an upgrade tool with a node, as long as we can do it one at a time > and as long as... > >> (3) network compatibility (from one cluster node to another): may >> change. If it does, we will notify you in NEWS.txt that you need to >> upgrade the whole cluster at once, as was the case for 0.4 -> 0.5. > > ...the network compat doesn't change at the same time. If both the > disk format and network protocol change in the same release, we can't > easy do a rolling restart/upgrade. > > In general, doing full cluster upgrades at once is going to be > prohibitively difficult for us. In addition to the disruption it would > cause for clients, we wouldn't want to throw away all of our > in-process caches at once.
I'd be comfortable committing to not breaking net compatibility in the same release as one that needs an upgrade tool to run on the data. I don't think we can freeze the network protocol entirely yet. > If we want the flexibility of changing the internal network protocol, > we should move towards an rpc framework that can tolerate upgrades. Thrift is supposed to tolerate upgrades... *cough* :) -Jonathan
