On Fri, Sep 1, 2017 at 2:23 PM, Stack <st...@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 <st...@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 >> >> >> >> >> >> >> >> >> >
