phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [DISCUSS] Road to HBase 2.0.0
Date Wed, 18 Oct 2017 18:50:17 GMT
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.
> 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

View raw message