hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: HBase wire compatibility
Date Tue, 14 Feb 2012 00:15:07 GMT
bq. Should we swat team it?

Or do this at the next Hackathon.

On Mon, Feb 13, 2012 at 4:09 PM, Stack <stack@duboce.net> wrote:

> On Mon, Feb 13, 2012 at 1:02 PM, Jimmy Xiang <jxiang@cloudera.com> wrote:
> > I posted the proposal on wiki:
> >
> > http://wiki.apache.org/hadoop/Hbase/HBaseWireCompatibility
> >
>
>
> Looks great.  Looking at Phase 1, we're talking about a big bang where
> we shut down cluster and come up on the new stuff w/ the new stuff
> migrating old formats to new; e.g. the content in .META.  When are we
> thinking we can take on the big bang?
>
> Looking at phase 2, it looks like another big bang (should phase 1 and
> phase 2 big bangs happen at same time)?
>
> Should we swat team it?  Go away for a weekend and bang it out?
>
> Can we make issues for each of the steps so we can discuss a bit of
> detail on each of the bullets?
>
> On:
>
> - Should pluggable encodings (thrift/avro/pb/writable) be in scope?
>
> I'd say no.
>
> On:
>
> - Should async IO servers and clients be in scope or not?
>
> I'd say no for now.
>
> On:
>
> - What is the policy for existing versions (89, 90, 92, 94) -- do we
> support them or require on major upgrade before they get this story?
>
> I'm not sure how else to do it.  How do you make an old client work
> against the new stuff?
>
> On:
>
> - Developers should be able to remove deprecated methods or arguments
> to maintain flexibility, but can't do that within the compatibility
> window. What should be our compatibility window? 2 years (roughly 4
> major versions)?
>
> Which compatibility window are you referring too?  Moving up on to
> this platform will be the singularity across nothing can cross, right?
>
> On:
>
> - What is the ZK version interoperability story?
>
> We need 3.4.x to support security.
>
> On:
>
> - What is the HDFS version interoperability story?
>
> None or at least out of scope for this project.  Its another project?
>
> On:
>
> - Should architectural-level changes require a major version bump?
>
> This is an interesting one.  For example, say we wanted to purge the
> -ROOT- region.  Well, that'd be something an old client could not
> tolerate.   So, you'd up the rpc version or figure how to purge -ROOT-
> in a way that old clients can still work (then there is no need to
> change rpc version -- to do a major version bump).
>
> St.Ack
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message