hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jimmy Xiang <jxi...@cloudera.com>
Subject Re: HBase wire compatibility
Date Tue, 14 Feb 2012 00:58:59 GMT
It is a good idea to swat team it or hackathon.


We'd like to start with phase 1 at first, then phase 2.

The purpose is to reduce/eliminate the operation interruption.  We need to
start from somewhere.

Thanks,
Jimmy

On Mon, Feb 13, 2012 at 4:15 PM, Ted Yu <yuzhihong@gmail.com> wrote:

> 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