Re: [DISCUSS] hbase-2.0.0 compatibility expectations

Thanks. I filed a JIRA to track it. https://issues.apache.org/jira/browse/HBASE-19145 On Mon, Oct 30, 2017 at 9:36 PM, Stack wrote: > On Mon, Oct 30, 2017 at 11:46 AM, Jerry He wrote: > >> Hi, Stack >> >> Coming back to this thread, i have meant to ask

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

On Mon, Oct 30, 2017 at 11:46 AM, Jerry He wrote: > Hi, Stack > > Coming back to this thread, i have meant to ask this question long ago. > Do we support hbase-2 client going against hbase-1 server? > It has not been an objective. It might work doing basic Client API on a

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

Hi, Stack Coming back to this thread, i have meant to ask this question long ago. Do we support hbase-2 client going against hbase-1 server? We seem to be fine mix-and-match the clients and servers within the hbase-1 releases. And IIRC hbase-1 client is ok against 0.98 server. Suppose I have a

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

Let me put this one on this thread, G1GC on by default in hbase2? St.Ack On Wed, Aug 2, 2017 at 4:38 PM, Stack 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

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

On Mon, Sep 4, 2017 at 6:55 PM, Francis Christopher Liu < toffer@gmail.com> wrote: > Just some high-level thoughts on rolling upgradeability (I'm repeating a > few things already said). > > 1. No service interruption for 1.x clients while a cluster is being > ugpraded to 2.x. - This

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

On Fri, Sep 1, 2017 at 3:12 PM, Sean Busbey 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

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

Just some high-level thoughts on rolling upgradeability (I'm repeating a few things already said). 1. No service interruption for 1.x clients while a cluster is being ugpraded to 2.x. - This includes support for apis commonly used in a running system: delegation tokens, getting region

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

The most of issues use hadoop flag, so the filter looks like this. project = HBASE AND fixVersion in (2.0.0, 2.0.0-alpha-1, 2.0.0-alpha-2, 2.0.0-alpha-3, 3.0) AND (labels in (incompatibleChange, incompatible, incompatibility) OR "Hadoop Flags" in ("Incompatible change")) On 2017-08-04 05:46,

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

Giving rolling-upgradable ability within branch-1, I'm inclined to push for our current stable release line,1.2. On Fri, Sep 1, 2017 at 2:24 PM, Stack wrote: > On Fri, Sep 1, 2017 at 2:23 PM, Stack wrote: > >> What versions should you be able to upgrade from?

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

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

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

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. Thanks, St.Ack On Wed, Aug 2, 2017 at 4:38 PM, Stack wrote: > What are our expectations regards compatibility between hbase1 and hbase2? > > Lets have a chat

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

On Thu, Aug 24, 2017 at 9:13 AM, stack wrote: > On Thu, Aug 3, 2017 at 11:05 PM, stack wrote: > >> Thanks Zach for clarification. Let me work up a list and then come back >> to this thread. Jira needs an edit pass to. >> >> > JIRA editing reflecting

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

On Thu, Aug 3, 2017 at 11:05 PM, stack wrote: > Thanks Zach for clarification. Let me work up a list and then come back to > this thread. Jira needs an edit pass to. > > JIRA editing reflecting incompatibles has been coming along. It is still a work-in-progress though.

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

Thanks Stack! -- Cloudera, Inc. On Mon, Aug 14, 2017 at 1:05 PM, Stack wrote: > On Fri, Aug 4, 2017 at 10:00 AM, Esteban Gutierrez > wrote: > > > Should we add additional details around replication as well? for > instance, > > shall we consider a

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

On Fri, Aug 11, 2017 at 5:07 PM, Apekshit Sharma wrote: > Ref: deleting/deprecating some methods in HBaseAdmin > https://github.com/apache/hbase/commit/de696cf6b653749c6bf105ef3d62d7 > a6c6923c57 > From first message: > *" An hbase1 client can run against an hbase2 cluster but

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

On Fri, Aug 4, 2017 at 10:00 AM, Esteban Gutierrez 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? > > Yes. I'd say this should be a blocker Esteban. Filed

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

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

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

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

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

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 wrote: >

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

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" wrote: This kinda helps, but these seem more like expectations. I was going more for things like HFile format

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

I expanded the condition in the filter like this: project = HBASE AND fixVersion in (2.0.0, 2.0.0-alpha-1, 2.0.0-alpha-2, 3.0) AND labels in (incompatibleChange, incompatible, incompatibility) Still there're only two showing up. On Thu, Aug 3, 2017 at 9:07 AM, Zach York

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

I tried to filter based on imcompatible labels and there were only two JIRAs returned [1]. I have a hard time believing that there were only two breaking changes from 1.x to 2.x. [1]

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

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

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

On Wed, Aug 2, 2017 at 5:25 PM, Zach York 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