hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [DISCUSS] hbase-2.0.0 compatibility expectations
Date Tue, 05 Sep 2017 17:41:00 GMT
On Fri, Sep 1, 2017 at 3:12 PM, Sean Busbey <busbey@apache.org> wrote:

> Giving rolling-upgradable ability within branch-1, I'm inclined to
> push for our current stable release line,1.2.
>
>
I like this suggestion. Any other opinions on minimum version from which
we'd support rolling upgrade?

S




> On Fri, Sep 1, 2017 at 2:24 PM, Stack <stack@duboce.net> wrote:
> > On Fri, Sep 1, 2017 at 2:23 PM, Stack <stack@duboce.net> wrote:
> >
> >> What versions should you be able to upgrade from? 1.0.0? 0.98.x? 1.2?
> I'm
> >> thinking 0.98 unless it means more work.
> >>
> >
> > Scratch that. Minimum is 1.0.0 I think given that is what I'm doing all
> > compat compares against and given we did API cleanup before we shipped
> > 1.0.0.
> > St.Ack
> >
> >
> >
> >> Thanks,
> >> St.Ack
> >>
> >> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
>

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