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 <els...@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
