hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: hbase 0.94.0
Date Thu, 02 Feb 2012 03:40:14 GMT
Hi,

>>Traditionally there have been no guarantees of cross major version
>>compatibility. RPC especially. Never a rolling upgrade from an 0.90 to an
>>0.92, for example. For persistent data, there is a migration utility for
>>upping from one major release to the next.
>
>I'm advocating that RPC compatibility breakage is not acceptable for FB
>because this is a vital and highly-deployed infrastructure piece.  I'm
>assuming this strategy may not be acceptable for other major contributors
>as well.

Of course. Traditionally or maybe "historically" HBase didn't made such guarantees because
of the level of resources available to the project. We lived with Hadoop RPC and its limitations,
there were other areas needing attention first. We supported a migration step only from one
major version to the next, because file formats were (and still are) in evolution. Now that
there are major contributors who can't accept a lack of cross major version compatibility,
I'm sure this will change fast, there are resources enough now to make it happen.

> What's the definition of working well enough to be 1.0?

I believe if you search the mailing list archives for "hadoop 1.0" you'll find the discussion
thread to which I refer.

Best regards,

    - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)


>________________________________
> From: Nicolas Spiegelberg <nspiegelberg@fb.com>
>To: "dev@hbase.apache.org" <dev@hbase.apache.org> 
>Sent: Monday, January 30, 2012 3:37 PM
>Subject: Re: hbase 0.94.0
> 
>>Traditionally there have been no guarantees of cross major version
>>compatibility. RPC especially. Never a rolling upgrade from an 0.90 to an
>>0.92, for example. For persistent data, there is a migration utility for
>>upping from one major release to the next.
>
>I'm advocating that RPC compatibility breakage is not acceptable for FB
>because this is a vital and highly-deployed infrastructure piece.  I'm
>assuming this strategy may not be acceptable for other major contributors
>as well.  I can't imagine that CDH customers don't need cross-version
>compat, which will most likely go from 92->96+.  I think we need to have a
>client->server online migration strategy for currently active revisions.
>This is independent of whether we label the current build 1.0 or not.  In
>fact, I would advocate that we want to be in the habit of cross-version
>compatibility and long-term thinking before we actually release a 1.0.
>With 1.0, we don't just want to have cross-version compat, we want to have
>the problem nailed or else it will cause major support problems.
>
>Note that I'm not advocating cross-service RPC compat at this time.  I
>don't think we need to tackle online rolling upgrades of HBase from 92->94
>(e.g. Mixed RegionServer versions or mixed master-RS).  Doing a start-stop
>of the entire HBase cluster is probably fine before 1.0.  However, I think
>it's safe to say that there are multiple instances where the DBA team and
>the AppServer team are different people, especially with any group
>exploring multi-tenancy.  For that use case, client & server compat is
>critical.
>
>
>>Regarding RPC, this state of affairs is not really acceptable to anyone
>>any more. Over in core there's work to move 99% of RPC to protobufs, with
>>only the thinnest Writable header. In this thread there seem several here
>>who want to tackle this for HBase now.
>
>Are the people working on this functionality are thinking about
>client-server compat?  JIRA #s?
>
>>Regarding major version data migrations, the attitude I believe is pre
>>1.0 we can entertain design changes that break compatibility, in search
>>of something that works well enough to be 1.0. From that point forward,
>>compatibility is a requirement.
>
>What's the definition of working well enough to be 1.0?  I thought having
>stable, durable PB+ online data storage would be considered working "well
>enough". Did we not declare that 0.90 was the "data durable" version of
>HBase that you could trust?  Migrations should be a first-class priority
>after declaring the project "data durable".  If you cannot reliably
>persist 100% of data after upgrade, then the version truly wasn't "data
>durable".
>
>
>
> 

Mime
View raw message