phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [DISCUSS] Road to HBase 2.0.0
Date Wed, 18 Oct 2017 18:51:59 GMT
> 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 <elserj@apache.org> 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 <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
>>>
>>>
>>


-- 
Best regards,
Andrew

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

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