Ref: deleting/deprecating some methods in HBaseAdmin https://github.com/apache/hbase/commit/de696cf6b653749c6bf105ef3d62d7a6c6923c57 >From first message: *" 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."*
Question 1: These guarantees are with what version of jars? Does the client has to keep using corresponding 1.x jars with which it was compiled, OR can the 2.x jars just replace earlier ones and client is still expected to work correctly? (i would say no!) Question second: How do we handle clients doing deprecated admin ops? a) make admin functions no-op by using empty method. b) throw exception. May/maynot crash the client - ideally shouldn't since methods are define with 'throws IOException'. c) delete the method - will crash the client But the question only makes sense if expect clients to work with 2.x jars. If not, we can just delete them, simple! Question 3: AMv2 related There are ops in old HBaseAdmin that'll be destructive for 2.0 (closeRegion() fn). If clients continue to use 1.x jars and make these calls, that's not acceptable. We need to handle such deprecation on server sider itself. If only there was way of versioning the rpc service! Another way, but bad one is, deprecate existing ones and move logic to a new one. I think there are just 1-2 that need this treatment. Either way, need to come up with a solution! On Fri, Aug 4, 2017 at 10:08 AM, Andrew Purtell <andrew.purt...@gmail.com> wrote: > This is a really good question. I think many operators will give a lot of > leeway to data format changes as long as data can be copied from A to B > (perhaps with batch rewrite to upgrade (ideally, not required)) and > replication can be enabled to sync up to the current moment for cut over. > > > > On Aug 4, 2017, at 10:00 AM, Esteban Gutierrez <este...@cloudera.com> > wrote: > > > > Should we add additional details around replication as well? for > instance, > > shall we consider a hbase-1.x cluster as a client for a hbase-2.x > cluster? > > > > Thanks for starting this discussion Stack, > > > > esteban. > > > > -- > > Cloudera, Inc. > > > > > >> On Fri, Aug 4, 2017 at 1:05 AM, stack <saint....@gmail.com> wrote: > >> > >> Thanks Zach for clarification. Let me work up a list and then come back > to > >> this thread. Jira needs an edit pass to. > >> > >> S > >> > >> On Aug 3, 2017 23:54, "Zach York" <zyork.contribut...@gmail.com> wrote: > >> > >> This kinda helps, but these seem more like expectations. I was going > more > >> for things like HFile format changed, meta table structure changed, > >> coprocessor implementations changed (these are just examples, I don't > know > >> if any of these actually changed). > >> > >> More technical differences between branch-1 and branch-2 which then can > >> help us get the right expectations for compatibility. > >> > >>> On Wed, Aug 2, 2017 at 6:34 PM, Stack <st...@duboce.net> wrote: > >>> > >>> On Wed, Aug 2, 2017 at 5:25 PM, Zach York < > zyork.contribut...@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 <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 > >>>>> > >>>> > >>> > >> > -- -- Appy
