On Mon, Jan 30, 2012 at 11:21 AM, Nicolas Spiegelberg <nspiegelb...@fb.com> wrote: > 1) The trunk has more master work. Specifically 89-master related > features that we implemented for our grid architecture. It sounds like > most of those features are rising in prominence in the Open Source > community as well (Ted from eBay & Todd from Cloudera, in particular). > Hopefully, we can collaborate on porting/implementation.
You have a list of issues Nicolas? > 2) Client/Server compatibility. Even if we upgraded the servers to > 94/96/whatever, we still will have a lot of clients running 89 & we can't > simply stop/start all of them at the same time. We need 89/trunk RPC > compat for client/server. An 0.89 client should be able to talk to a 0.94+ server? > 3) Durable Server Upgrade. It does bother me that people are very quick > to consider removing both RPC & persistent data compatibility from 90 to > trunk (a branch that we're still actively releasing minor upgrades for). > We will need the ability to mutate the HDFS & ZK persistent data from the > 89 format to trunk. Specifically, work like HFileV1 reader is critical > for analysis if the upgrade script fails and we need to debug. > The talk was of removing old code if no longer needed; i.e you should not have the condition you describe above of having to have an hfilev1 reader during upgrade if we had it that you couldn't start an upgrade w/o first purging hfilev1s. The rpc incompatibility across major versions is to be undone in future versions. I'm just trying to elicit if you think we need to be able to make it work back into the past. If so, thats a new requirement. > Instead of discussing what classes we can throw away, can we instead think > about a strategy for long-term, cross-version compatibility that minimally > hurts trunk development? Is HFileV1's presence severely hindering another > feature? > Unused code should be let go. Its a drag. Long term cross-version compatibility, as Jon says later, is being started on.... proposal coming. St.Ack
