hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: hbase 0.94.0
Date Tue, 31 Jan 2012 05:39:19 GMT
On Mon, Jan 30, 2012 at 11:21 AM, Nicolas Spiegelberg
<nspiegelberg@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

> 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


View raw message