phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: [DISCUSS] Road to HBase 2.0.0
Date Fri, 13 Oct 2017 21:40:23 GMT
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 <elserj@apache.org> 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 <elserj@apache.org> 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
>>>
>>

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