Re: [DISCUSS] Road to HBase 2.0.0

[Josh Elser]

Just had an offlist chat with Sergey, Rajeshbabu, and Ankit.

FYI you all will probably see a branch show up soon which includes the 
necessary HBase 2.0 changes (the work primarily outlined in 
PHOENIX-4297). This branch will probably be in a flux for a while 
(questionable states of compilation/test-failure).


I wanted to make sure that folks who had the time/interest to contribute 
to the not-so-fun effort were able to ;). Will share a branch name when 
I see it.


On 10/11/17 6:00 PM, Josh Elser wrote:
Since 4.12.0 is out and we have the concurrent discussions about the 
0.98, 1.1, and 1.2 HBase branches, do folks have a vision of how we get 
to HBase 2.0.0?


The lack of chatter is pretty obvious that the Calcite work (the 
previous impetus for Phoenix 5) has slowed. Once we get to an HBase 
2.0.0-alpha4, coprocessor API should stabilize and give us a point 
against which we can start Phoenix work.


Should a release of Phoenix that supports HBase 2.0 be worthy of the 
Phoenix 5.0 label, or should we stick to the 4.x numbering? Given the 
breaking changes going into HBase 2.0 and James' previous -1 to 
shim-layers for 0.98, do we see the same for an HBase 2.0 branch or is 
HBase 1.x/2.x a different beast? I can see pros/cons for both sides.


- Josh

Re: [DISCUSS] Road to HBase 2.0.0

[Andrew Purtell]

Thanks James!

On Wed, Oct 18, 2017 at 3:52 PM, James Taylor 
wrote:

> FYI, I filed JIRAs for the Phoenix changes we talked about in the
> spreadsheet and labeled them all with HBase-2.0 [1].
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%
> 20resolution%20%3D%20Unresolved%20AND%20labels%3D%22HBase-2.0%22
>
> On Wed, Oct 18, 2017 at 3:38 PM, Stack  wrote:
>
> > On Wed, Oct 18, 2017 at 12:13 PM, Josh Elser  wrote:
> >
> > >
> > > On 10/18/17 2:51 PM, Andrew Purtell wrote:
> > >
> > >> Hopefully, Phoenix will not find itself in a position where
> > >>>
> > >> business-critical things it's doing are being removed from API (and
> > >> Phoenix
> > >> has no recourse to hack what it needs back in place).
> > >>
> > >> I feel fairly confident this is going to happen given the radical
> > excision
> > >> of methods from the interfaces. What I hope is we can get a round of
> > >> evaluation by the Phoenix folks of the fallout in between our
> > introduction
> > >> of these changes in an alpha before we cement the changes in a GA
> > release.
> > >>
> > >
> > > /me nods
> > >
> > > I know Ankit and Rajeshbabu have already started looking at this
> > > internally (I'll take the blame there -- I didn't expect 4.12 to go out
> > the
> > > door so quickly, I had recommended they just do it locally for now).
> > >
> > > I've asked them to pull the work they've done in porting out to Apache.
> > > I'm expecting that we'll see them push up a branch with what they have
> > > tomorrow :)
> > >
> > > Getting us to a place where we have a branch of Phoenix with the
> > necessary
> > > HBase 2.0 fixes in place is the path forward I see. I'll help out as
> much
> > > as I can here too.
> > >
> >
> >
> > Post-alpha-4, can we soon-after organize a few hours where a bunch of us
> > work on bringing Phoenix over together all sitting in the one hangout? As
> > per Andrew, a bunch of stuff is being purged (access to Private classes
> > mostly, etc.) but there is usually an alternate route. A lone Phoenixer
> > trying to figure it may get lost. If those of us who have been working on
> > the CP hackup were to-hand, we could show(doc)-the-way or if none,
> > plumb-the-way and get the new routes in before 2.0.0RC0.
> >
> > Thanks,
> > S
> >
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] Road to HBase 2.0.0

[James Taylor]

FYI, I filed JIRAs for the Phoenix changes we talked about in the
spreadsheet and labeled them all with HBase-2.0 [1].

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%3D%22HBase-2.0%22

On Wed, Oct 18, 2017 at 3:38 PM, Stack  wrote:

> On Wed, Oct 18, 2017 at 12:13 PM, Josh Elser  wrote:
>
> >
> > On 10/18/17 2:51 PM, Andrew Purtell wrote:
> >
> >> Hopefully, Phoenix will not find itself in a position where
> >>>
> >> business-critical things it's doing are being removed from API (and
> >> Phoenix
> >> has no recourse to hack what it needs back in place).
> >>
> >> I feel fairly confident this is going to happen given the radical
> excision
> >> of methods from the interfaces. What I hope is we can get a round of
> >> evaluation by the Phoenix folks of the fallout in between our
> introduction
> >> of these changes in an alpha before we cement the changes in a GA
> release.
> >>
> >
> > /me nods
> >
> > I know Ankit and Rajeshbabu have already started looking at this
> > internally (I'll take the blame there -- I didn't expect 4.12 to go out
> the
> > door so quickly, I had recommended they just do it locally for now).
> >
> > I've asked them to pull the work they've done in porting out to Apache.
> > I'm expecting that we'll see them push up a branch with what they have
> > tomorrow :)
> >
> > Getting us to a place where we have a branch of Phoenix with the
> necessary
> > HBase 2.0 fixes in place is the path forward I see. I'll help out as much
> > as I can here too.
> >
>
>
> Post-alpha-4, can we soon-after organize a few hours where a bunch of us
> work on bringing Phoenix over together all sitting in the one hangout? As
> per Andrew, a bunch of stuff is being purged (access to Private classes
> mostly, etc.) but there is usually an alternate route. A lone Phoenixer
> trying to figure it may get lost. If those of us who have been working on
> the CP hackup were to-hand, we could show(doc)-the-way or if none,
> plumb-the-way and get the new routes in before 2.0.0RC0.
>
> Thanks,
> S
>

Re: [DISCUSS] Road to HBase 2.0.0

[Stack]

On Wed, Oct 18, 2017 at 12:13 PM, Josh Elser  wrote:

>
> On 10/18/17 2:51 PM, Andrew Purtell wrote:
>
>> Hopefully, Phoenix will not find itself in a position where
>>>
>> business-critical things it's doing are being removed from API (and
>> Phoenix
>> has no recourse to hack what it needs back in place).
>>
>> I feel fairly confident this is going to happen given the radical excision
>> of methods from the interfaces. What I hope is we can get a round of
>> evaluation by the Phoenix folks of the fallout in between our introduction
>> of these changes in an alpha before we cement the changes in a GA release.
>>
>
> /me nods
>
> I know Ankit and Rajeshbabu have already started looking at this
> internally (I'll take the blame there -- I didn't expect 4.12 to go out the
> door so quickly, I had recommended they just do it locally for now).
>
> I've asked them to pull the work they've done in porting out to Apache.
> I'm expecting that we'll see them push up a branch with what they have
> tomorrow :)
>
> Getting us to a place where we have a branch of Phoenix with the necessary
> HBase 2.0 fixes in place is the path forward I see. I'll help out as much
> as I can here too.
>


Post-alpha-4, can we soon-after organize a few hours where a bunch of us
work on bringing Phoenix over together all sitting in the one hangout? As
per Andrew, a bunch of stuff is being purged (access to Private classes
mostly, etc.) but there is usually an alternate route. A lone Phoenixer
trying to figure it may get lost. If those of us who have been working on
the CP hackup were to-hand, we could show(doc)-the-way or if none,
plumb-the-way and get the new routes in before 2.0.0RC0.

Thanks,
S

Re: [DISCUSS] Road to HBase 2.0.0

[Josh Elser]

On 10/18/17 2:51 PM, Andrew Purtell wrote:

Hopefully, Phoenix will not find itself in a position where

business-critical things it's doing are being removed from API (and Phoenix
has no recourse to hack what it needs back in place).

I feel fairly confident this is going to happen given the radical excision
of methods from the interfaces. What I hope is we can get a round of
evaluation by the Phoenix folks of the fallout in between our introduction
of these changes in an alpha before we cement the changes in a GA release.


/me nods

I know Ankit and Rajeshbabu have already started looking at this 
internally (I'll take the blame there -- I didn't expect 4.12 to go out 
the door so quickly, I had recommended they just do it locally for now).


I've asked them to pull the work they've done in porting out to Apache. 
I'm expecting that we'll see them push up a branch with what they have 
tomorrow :)


Getting us to a place where we have a branch of Phoenix with the 
necessary HBase 2.0 fixes in place is the path forward I see. I'll help 
out as much as I can here too.

Re: [DISCUSS] Road to HBase 2.0.0

[Andrew Purtell]

> Hopefully, Phoenix will not find itself in a position where
business-critical things it's doing are being removed from API (and Phoenix
has no recourse to hack what it needs back in place).

I feel fairly confident this is going to happen given the radical excision
of methods from the interfaces. What I hope is we can get a round of
evaluation by the Phoenix folks of the fallout in between our introduction
of these changes in an alpha before we cement the changes in a GA release.


On Wed, Oct 18, 2017 at 11:50 AM, Josh Elser  wrote:

> Yes, the earlier the better, but this is also a bit chicken-and-egg. It's
> tough down in Phoenix to make sure it still works if the API we're trying
> to write against is still changing.
>
> I know that Anoop from the HBase side has been peering into the Phoenix
> side -- I've been operating under the assumption that things will be OK.
> Hopefully, Phoenix will not find itself in a position where
> business-critical things it's doing are being removed from API (and Phoenix
> has no recourse to hack what it needs back in place).
>
> With an HBase hat on, I think Phoenix is a good candidate (among others
> like YARN) for validating the alpha-4 release, signaling whether we're
> actually ready to say HBase 2 is ready for a beta-1 (as opposed to an
> alpha-5 to fix some more).
>
> Happy to entertain a broader discussion if you think there's merit on
> dev@hbase too, S.
>
>
> On 10/17/17 5:35 PM, Stack wrote:
>
>> Some notes on this effort:
>>
>> + Perhaps this discussion should be cc'd to dev@hbase? There is a good
>> bit
>> of overlap between dev-set here and dev-set on hbase and some
>> interest/concern around Phoenix on HBase2.
>> + Here are some notes I took after looking at Phoenix last week that I ran
>> by James off-list (I filled in some of his feedback) [1]. The notes try to
>> list what Phoenix uses from HBase core. I was looking to Coprocessor usage
>> mostly. I noticed that CP-usage is mostly inside the bounds of appropriate
>> use. It is elsewhere that P is in violation.
>> + After my splunking and going by feedback from James, do we have to carry
>> all of Phoenix over to hbase2? Can we drop some stuff that is not used
>> anymore or can we work out an ordained API P could use instead of do its
>> own workaround?
>>
>> It is late in the day to be having this conversation -- we are about to
>> release alpha4 which is supposed to be locked-down internal and external
>> API -- but better late than never.
>>
>> Thanks,
>> St.Ack
>> 1.  https://docs.google.com/document/d/10cabwp_
>> aR3OmpHVoeh544YLC3KwqMD9KiTIrHZAmfec/edit#heading=h.7swwa1jl6wiw
>>
>> On Wed, Oct 11, 2017 at 3:00 PM, Josh Elser  wrote:
>>
>> Since 4.12.0 is out and we have the concurrent discussions about the 0.98,
>>> 1.1, and 1.2 HBase branches, do folks have a vision of how we get to
>>> HBase
>>> 2.0.0?
>>>
>>> The lack of chatter is pretty obvious that the Calcite work (the previous
>>> impetus for Phoenix 5) has slowed. Once we get to an HBase 2.0.0-alpha4,
>>> coprocessor API should stabilize and give us a point against which we can
>>> start Phoenix work.
>>>
>>> Should a release of Phoenix that supports HBase 2.0 be worthy of the
>>> Phoenix 5.0 label, or should we stick to the 4.x numbering? Given the
>>> breaking changes going into HBase 2.0 and James' previous -1 to
>>> shim-layers
>>> for 0.98, do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x
>>> a
>>> different beast? I can see pros/cons for both sides.
>>>
>>> - Josh
>>>
>>>
>>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] Road to HBase 2.0.0

[Josh Elser]

Yes, the earlier the better, but this is also a bit chicken-and-egg. 
It's tough down in Phoenix to make sure it still works if the API we're 
trying to write against is still changing.


I know that Anoop from the HBase side has been peering into the Phoenix 
side -- I've been operating under the assumption that things will be OK. 
Hopefully, Phoenix will not find itself in a position where 
business-critical things it's doing are being removed from API (and 
Phoenix has no recourse to hack what it needs back in place).


With an HBase hat on, I think Phoenix is a good candidate (among others 
like YARN) for validating the alpha-4 release, signaling whether we're 
actually ready to say HBase 2 is ready for a beta-1 (as opposed to an 
alpha-5 to fix some more).


Happy to entertain a broader discussion if you think there's merit on 
dev@hbase too, S.


On 10/17/17 5:35 PM, Stack wrote:

Some notes on this effort:

+ Perhaps this discussion should be cc'd to dev@hbase? There is a good bit
of overlap between dev-set here and dev-set on hbase and some
interest/concern around Phoenix on HBase2.
+ Here are some notes I took after looking at Phoenix last week that I ran
by James off-list (I filled in some of his feedback) [1]. The notes try to
list what Phoenix uses from HBase core. I was looking to Coprocessor usage
mostly. I noticed that CP-usage is mostly inside the bounds of appropriate
use. It is elsewhere that P is in violation.
+ After my splunking and going by feedback from James, do we have to carry
all of Phoenix over to hbase2? Can we drop some stuff that is not used
anymore or can we work out an ordained API P could use instead of do its
own workaround?

It is late in the day to be having this conversation -- we are about to
release alpha4 which is supposed to be locked-down internal and external
API -- but better late than never.

Thanks,
St.Ack
1.  https://docs.google.com/document/d/10cabwp_
aR3OmpHVoeh544YLC3KwqMD9KiTIrHZAmfec/edit#heading=h.7swwa1jl6wiw

On Wed, Oct 11, 2017 at 3:00 PM, Josh Elser  wrote:


Since 4.12.0 is out and we have the concurrent discussions about the 0.98,
1.1, and 1.2 HBase branches, do folks have a vision of how we get to HBase
2.0.0?

The lack of chatter is pretty obvious that the Calcite work (the previous
impetus for Phoenix 5) has slowed. Once we get to an HBase 2.0.0-alpha4,
coprocessor API should stabilize and give us a point against which we can
start Phoenix work.

Should a release of Phoenix that supports HBase 2.0 be worthy of the
Phoenix 5.0 label, or should we stick to the 4.x numbering? Given the
breaking changes going into HBase 2.0 and James' previous -1 to shim-layers
for 0.98, do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x a
different beast? I can see pros/cons for both sides.

- Josh

Re: [DISCUSS] Road to HBase 2.0.0

[Stack]

Some notes on this effort:

+ Perhaps this discussion should be cc'd to dev@hbase? There is a good bit
of overlap between dev-set here and dev-set on hbase and some
interest/concern around Phoenix on HBase2.
+ Here are some notes I took after looking at Phoenix last week that I ran
by James off-list (I filled in some of his feedback) [1]. The notes try to
list what Phoenix uses from HBase core. I was looking to Coprocessor usage
mostly. I noticed that CP-usage is mostly inside the bounds of appropriate
use. It is elsewhere that P is in violation.
+ After my splunking and going by feedback from James, do we have to carry
all of Phoenix over to hbase2? Can we drop some stuff that is not used
anymore or can we work out an ordained API P could use instead of do its
own workaround?

It is late in the day to be having this conversation -- we are about to
release alpha4 which is supposed to be locked-down internal and external
API -- but better late than never.

Thanks,
St.Ack
1.  https://docs.google.com/document/d/10cabwp_
aR3OmpHVoeh544YLC3KwqMD9KiTIrHZAmfec/edit#heading=h.7swwa1jl6wiw

On Wed, Oct 11, 2017 at 3:00 PM, Josh Elser  wrote:

> Since 4.12.0 is out and we have the concurrent discussions about the 0.98,
> 1.1, and 1.2 HBase branches, do folks have a vision of how we get to HBase
> 2.0.0?
>
> The lack of chatter is pretty obvious that the Calcite work (the previous
> impetus for Phoenix 5) has slowed. Once we get to an HBase 2.0.0-alpha4,
> coprocessor API should stabilize and give us a point against which we can
> start Phoenix work.
>
> Should a release of Phoenix that supports HBase 2.0 be worthy of the
> Phoenix 5.0 label, or should we stick to the 4.x numbering? Given the
> breaking changes going into HBase 2.0 and James' previous -1 to shim-layers
> for 0.98, do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x a
> different beast? I can see pros/cons for both sides.
>
> - Josh
>

Re: [DISCUSS] Road to HBase 2.0.0

[Josh Elser]

+1 James' plan is similar to what I had in mind. I think the quicker we 
can get a branch in place to build against HBase2, the quicker we can 
find and fix all of these rough edges.


Great list you have here, Sergey. Will certainly be helpful.

Ankit/Rajeshbabu, did you guys have anything to add here? Could I 
encourage you to "run" with James' idea and start implementing some of 
these changes?


On 10/13/17 6:28 PM, Sergey Soldatov wrote:

There is a list of problems that we need to fix to get it working with
HBase 2.0:
1. renamed methods (such as add => addColumn). That's the easiest to fix
2. removed interfaces such as HTableInterface. We are supposed to use Table
now. That may lead to some small difference between branches. Because
that's funny, but there are some HBase 1.x methods are using deprecated
API, but have no duplicated methods that appears only in 2.0. The same
thing with KeyValue => Cell if I remember correctly.
3. Our wrappers for HTable/etc. Since the set of methods sometimes very
different for 1.x and 2.0, we will need to maintain different versions.
Luckily that's one time work and maintaining would not be hard because we
rarely change them.
4. Some renaming would be required. I can recall KeyValueUtil, possible
some else to avoid ambiguity between our and HBase classes.
5. signature some of methods has been changed. Like batch() now doesn't
return the result, but requires it as an argument
6. Many methods switched from using byte[] to TableName. Don't remember,
but possible that works fine with 1.x, so it can be part of (1)
refactoring.
7. new Coprocessors. I have no idea how many changes we will have, because
my previous attempts to get it working with HBase 2.0 were far before new
implementation.

I support the roadmap provided by James. Most of the changes I listed
(300+K patch) can be done as the first bullet in his list.

Thanks,
Sergey

On Fri, Oct 13, 2017 at 2:40 PM, James Taylor 
wrote:


One idea of where to put the code:
- switch to using non deprecated HBase methods in master
- same for Tephra
- create a 5.0-HBase-2.0 branch to put code specific to getting Phoenix to
work against HBase 2.0
- take a look at the changes and see if a shim layer makes sense (I'm only
-1 on an HBase 0.98 shim layer because the life span of that branch is very
limited)
- eventually make 5.0-HBase-2.0 the master branch

Thoughts?

On Fri, Oct 13, 2017 at 8:31 AM, Josh Elser  wrote:


Thanks, Anoop!

I know Sergey, Ankit, and Rajeshbabu have been looking at this already.

While tracking it is good, I think we still need to come up with a plan
for where we're going to put that new code in Phoenix :)


On 10/13/17 6:58 AM, Anoop John wrote:


Thanks for bringing this up.  I was abt to ask this.  Ya the CP
framework itself and the CP exposed interfaces (Like
RegionServerServices, Region etc) are undergoing a big change for for
HBase 2.0..  I did  a look at some of the usages of the Phoenix
exposed interfaces/classes.  There are some items for fix.   Was
thinking to raise an umbrella issue once we have a plan for the
version based on HBase 2.0

-Anoop-

On Thu, Oct 12, 2017 at 3:30 AM, Josh Elser  wrote:


Since 4.12.0 is out and we have the concurrent discussions about the
0.98,
1.1, and 1.2 HBase branches, do folks have a vision of how we get to
HBase
2.0.0?

The lack of chatter is pretty obvious that the Calcite work (the

previous

impetus for Phoenix 5) has slowed. Once we get to an HBase

2.0.0-alpha4,

coprocessor API should stabilize and give us a point against which we

can

start Phoenix work.

Should a release of Phoenix that supports HBase 2.0 be worthy of the
Phoenix
5.0 label, or should we stick to the 4.x numbering? Given the breaking
changes going into HBase 2.0 and James' previous -1 to shim-layers for
0.98,
do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x a
different
beast? I can see pros/cons for both sides.

- Josh

Re: [DISCUSS] Road to HBase 2.0.0

[Sergey Soldatov]

There is a list of problems that we need to fix to get it working with
HBase 2.0:
1. renamed methods (such as add => addColumn). That's the easiest to fix
2. removed interfaces such as HTableInterface. We are supposed to use Table
now. That may lead to some small difference between branches. Because
that's funny, but there are some HBase 1.x methods are using deprecated
API, but have no duplicated methods that appears only in 2.0. The same
thing with KeyValue => Cell if I remember correctly.
3. Our wrappers for HTable/etc. Since the set of methods sometimes very
different for 1.x and 2.0, we will need to maintain different versions.
Luckily that's one time work and maintaining would not be hard because we
rarely change them.
4. Some renaming would be required. I can recall KeyValueUtil, possible
some else to avoid ambiguity between our and HBase classes.
5. signature some of methods has been changed. Like batch() now doesn't
return the result, but requires it as an argument
6. Many methods switched from using byte[] to TableName. Don't remember,
but possible that works fine with 1.x, so it can be part of (1)
refactoring.
7. new Coprocessors. I have no idea how many changes we will have, because
my previous attempts to get it working with HBase 2.0 were far before new
implementation.

I support the roadmap provided by James. Most of the changes I listed
(300+K patch) can be done as the first bullet in his list.

Thanks,
Sergey

On Fri, Oct 13, 2017 at 2:40 PM, James Taylor 
wrote:

> One idea of where to put the code:
> - switch to using non deprecated HBase methods in master
> - same for Tephra
> - create a 5.0-HBase-2.0 branch to put code specific to getting Phoenix to
> work against HBase 2.0
> - take a look at the changes and see if a shim layer makes sense (I'm only
> -1 on an HBase 0.98 shim layer because the life span of that branch is very
> limited)
> - eventually make 5.0-HBase-2.0 the master branch
>
> Thoughts?
>
> On Fri, Oct 13, 2017 at 8:31 AM, Josh Elser  wrote:
>
> > Thanks, Anoop!
> >
> > I know Sergey, Ankit, and Rajeshbabu have been looking at this already.
> >
> > While tracking it is good, I think we still need to come up with a plan
> > for where we're going to put that new code in Phoenix :)
> >
> >
> > On 10/13/17 6:58 AM, Anoop John wrote:
> >
> >> Thanks for bringing this up.  I was abt to ask this.  Ya the CP
> >> framework itself and the CP exposed interfaces (Like
> >> RegionServerServices, Region etc) are undergoing a big change for for
> >> HBase 2.0..  I did  a look at some of the usages of the Phoenix
> >> exposed interfaces/classes.  There are some items for fix.   Was
> >> thinking to raise an umbrella issue once we have a plan for the
> >> version based on HBase 2.0
> >>
> >> -Anoop-
> >>
> >> On Thu, Oct 12, 2017 at 3:30 AM, Josh Elser  wrote:
> >>
> >>> Since 4.12.0 is out and we have the concurrent discussions about the
> >>> 0.98,
> >>> 1.1, and 1.2 HBase branches, do folks have a vision of how we get to
> >>> HBase
> >>> 2.0.0?
> >>>
> >>> The lack of chatter is pretty obvious that the Calcite work (the
> previous
> >>> impetus for Phoenix 5) has slowed. Once we get to an HBase
> 2.0.0-alpha4,
> >>> coprocessor API should stabilize and give us a point against which we
> can
> >>> start Phoenix work.
> >>>
> >>> Should a release of Phoenix that supports HBase 2.0 be worthy of the
> >>> Phoenix
> >>> 5.0 label, or should we stick to the 4.x numbering? Given the breaking
> >>> changes going into HBase 2.0 and James' previous -1 to shim-layers for
> >>> 0.98,
> >>> do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x a
> >>> different
> >>> beast? I can see pros/cons for both sides.
> >>>
> >>> - Josh
> >>>
> >>
>

Re: [DISCUSS] Road to HBase 2.0.0

[James Taylor]

One idea of where to put the code:
- switch to using non deprecated HBase methods in master
- same for Tephra
- create a 5.0-HBase-2.0 branch to put code specific to getting Phoenix to
work against HBase 2.0
- take a look at the changes and see if a shim layer makes sense (I'm only
-1 on an HBase 0.98 shim layer because the life span of that branch is very
limited)
- eventually make 5.0-HBase-2.0 the master branch

Thoughts?

On Fri, Oct 13, 2017 at 8:31 AM, Josh Elser  wrote:

> Thanks, Anoop!
>
> I know Sergey, Ankit, and Rajeshbabu have been looking at this already.
>
> While tracking it is good, I think we still need to come up with a plan
> for where we're going to put that new code in Phoenix :)
>
>
> On 10/13/17 6:58 AM, Anoop John wrote:
>
>> Thanks for bringing this up.  I was abt to ask this.  Ya the CP
>> framework itself and the CP exposed interfaces (Like
>> RegionServerServices, Region etc) are undergoing a big change for for
>> HBase 2.0..  I did  a look at some of the usages of the Phoenix
>> exposed interfaces/classes.  There are some items for fix.   Was
>> thinking to raise an umbrella issue once we have a plan for the
>> version based on HBase 2.0
>>
>> -Anoop-
>>
>> On Thu, Oct 12, 2017 at 3:30 AM, Josh Elser  wrote:
>>
>>> Since 4.12.0 is out and we have the concurrent discussions about the
>>> 0.98,
>>> 1.1, and 1.2 HBase branches, do folks have a vision of how we get to
>>> HBase
>>> 2.0.0?
>>>
>>> The lack of chatter is pretty obvious that the Calcite work (the previous
>>> impetus for Phoenix 5) has slowed. Once we get to an HBase 2.0.0-alpha4,
>>> coprocessor API should stabilize and give us a point against which we can
>>> start Phoenix work.
>>>
>>> Should a release of Phoenix that supports HBase 2.0 be worthy of the
>>> Phoenix
>>> 5.0 label, or should we stick to the 4.x numbering? Given the breaking
>>> changes going into HBase 2.0 and James' previous -1 to shim-layers for
>>> 0.98,
>>> do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x a
>>> different
>>> beast? I can see pros/cons for both sides.
>>>
>>> - Josh
>>>
>>

Re: [DISCUSS] Road to HBase 2.0.0

[Josh Elser]

Thanks, Anoop!

I know Sergey, Ankit, and Rajeshbabu have been looking at this already.

While tracking it is good, I think we still need to come up with a plan 
for where we're going to put that new code in Phoenix :)


On 10/13/17 6:58 AM, Anoop John wrote:

Thanks for bringing this up.  I was abt to ask this.  Ya the CP
framework itself and the CP exposed interfaces (Like
RegionServerServices, Region etc) are undergoing a big change for for
HBase 2.0..  I did  a look at some of the usages of the Phoenix
exposed interfaces/classes.  There are some items for fix.   Was
thinking to raise an umbrella issue once we have a plan for the
version based on HBase 2.0

-Anoop-

On Thu, Oct 12, 2017 at 3:30 AM, Josh Elser  wrote:

Since 4.12.0 is out and we have the concurrent discussions about the 0.98,
1.1, and 1.2 HBase branches, do folks have a vision of how we get to HBase
2.0.0?

The lack of chatter is pretty obvious that the Calcite work (the previous
impetus for Phoenix 5) has slowed. Once we get to an HBase 2.0.0-alpha4,
coprocessor API should stabilize and give us a point against which we can
start Phoenix work.

Should a release of Phoenix that supports HBase 2.0 be worthy of the Phoenix
5.0 label, or should we stick to the 4.x numbering? Given the breaking
changes going into HBase 2.0 and James' previous -1 to shim-layers for 0.98,
do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x a different
beast? I can see pros/cons for both sides.

- Josh

Re: [DISCUSS] Road to HBase 2.0.0

[Anoop John]

Thanks for bringing this up.  I was abt to ask this.  Ya the CP
framework itself and the CP exposed interfaces (Like
RegionServerServices, Region etc) are undergoing a big change for for
HBase 2.0..  I did  a look at some of the usages of the Phoenix
exposed interfaces/classes.  There are some items for fix.   Was
thinking to raise an umbrella issue once we have a plan for the
version based on HBase 2.0

-Anoop-

On Thu, Oct 12, 2017 at 3:30 AM, Josh Elser  wrote:
> Since 4.12.0 is out and we have the concurrent discussions about the 0.98,
> 1.1, and 1.2 HBase branches, do folks have a vision of how we get to HBase
> 2.0.0?
>
> The lack of chatter is pretty obvious that the Calcite work (the previous
> impetus for Phoenix 5) has slowed. Once we get to an HBase 2.0.0-alpha4,
> coprocessor API should stabilize and give us a point against which we can
> start Phoenix work.
>
> Should a release of Phoenix that supports HBase 2.0 be worthy of the Phoenix
> 5.0 label, or should we stick to the 4.x numbering? Given the breaking
> changes going into HBase 2.0 and James' previous -1 to shim-layers for 0.98,
> do we see the same for an HBase 2.0 branch or is HBase 1.x/2.x a different
> beast? I can see pros/cons for both sides.
>
> - Josh