Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: <CAN+qs_NsAy-bc13xgdBwRSDoKQ-QyMOvYsrH73gP-_yCkpQeXg@mail.gmail.com>
References: <CADcMMgHpEYHBUVYZfp1VhWob7B=ayC8DwTBE7bje_ZZ9Ff1-nQ@mail.gmail.com>
 <CAN+qs_NsAy-bc13xgdBwRSDoKQ-QyMOvYsrH73gP-_yCkpQeXg@mail.gmail.com>
From: Stack <stack@duboce.net>
Date: Wed, 2 Aug 2017 18:34:42 -0700
Message-ID: <CADcMMgEmkSqWZ-UPbPWBXqesK8CbZn1QwCp-y+EG=NWbSyzMPA@mail.gmail.com>
Subject: Re: [DISCUSS] hbase-2.0.0 compatibility expectations
To: HBase Dev List <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary="94eb2c065a408732b00555cf62d8"
archived-at: Thu, 03 Aug 2017 01:34:52 -0000

--94eb2c065a408732b00555cf62d8
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 2, 2017 at 5:25 PM, Zach York <zyork.contribution@gmail.com>
wrote:

> Do we know what the major pain points for migration are? Can we discuss
> that/get a list going?
>
>
Here's a few in outline:

+ There is issue of formats, of hbase-2.x being able to read hbase-1.x data
whether from HDFS or ZooKeeper or off the wire.
+ An hbase-1.x client should be able to Get/Put and Scan an hbase-2.x
cluster; no holes in the API or unintelligible serializations.
+ There is then the little dance that has us rolling restart from an
hbase-1.x cluster to hbase-2.x; i.e. upgrade master first and then it will
assign regions to the new hbase-2.x regionservers as they come on line. TBD.

Is this what you mean sir?

S


> I think without that knowledge it is hard (for me at least :) ) to
> determine where we should set our sights in terms of migration.
>
> Thanks,
> Zach
>
> On Wed, Aug 2, 2017 at 4:38 PM, Stack <stack@duboce.net> wrote:
>
> > What are our expectations regards compatibility between hbase1 and
> hbase2?
> >
> > Lets have a chat about it. Here are some goal posts.
> >
> > + You have to upgrade to hbase-1.x before you can migrate to hbase-2. No
> > migration from < hbase-1 (Is this too onerous? Should we support 0.98 =>
> > 2.0?).
> > + You do NOT have to upgrade to the latest release of hbase1 to migrate
> to
> > hbase2; being up on hbase-1.0.0+ will be sufficient.
> > + You'll have to update your hbase1 coprocessors to deploy them on
> hbase2.
> > A bunch of CP API has/will change by the time hbase2 comes out; e.g.
> > watching for region split on RegionServer no longer makes sense given
> > Master runs all splits now.
> > + An hbase1 client can run against an hbase2 cluster but it will only be
> > able to do DML (Get/Put/Scan, etc.). We do not allow being able to do
> admin
> > ops using an hbase1 Admin client against an hbase2 cluster. We have some
> > egregious API violations in branch-1; e.g. we have protobuf in our API
> (See
> > HBASE-15607). The notion is that we can't afford a deprecation cycle
> > purging this stuff from our Admin API.
> >
> > What you all think?
> >
> > St.Ack
> >
>

--94eb2c065a408732b00555cf62d8--