Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 70F4E200D1F for ; Fri, 13 Oct 2017 23:40:27 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 6F3BC1609E9; Fri, 13 Oct 2017 21:40:27 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id B58F51609CA for ; Fri, 13 Oct 2017 23:40:26 +0200 (CEST) Received: (qmail 43684 invoked by uid 500); 13 Oct 2017 21:40:25 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 43673 invoked by uid 99); 13 Oct 2017 21:40:25 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Oct 2017 21:40:25 +0000 Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 885B51A0140 for ; Fri, 13 Oct 2017 21:40:25 +0000 (UTC) Received: by mail-qk0-f181.google.com with SMTP id k123so6651008qke.3 for ; Fri, 13 Oct 2017 14:40:25 -0700 (PDT) X-Gm-Message-State: AMCzsaXmWqof9E/IpbMepbGkVyjmvxla24InR5DvcdMBpT4GOJzxOOiS /Z6xMsNkCL0lfxgGfEiqmocpztPugpyTeZr4/BY= X-Google-Smtp-Source: AOwi7QCbn94eI4/6P1/UPZCp+gEjlgEfJm2GRUH0xsDWSLXikorYYcv/5cE+snYdhG/mmz01X7G/dMAk1nuKBB2Eu3c= X-Received: by 10.55.161.200 with SMTP id k191mr4225459qke.158.1507930824156; Fri, 13 Oct 2017 14:40:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.149.73 with HTTP; Fri, 13 Oct 2017 14:40:23 -0700 (PDT) In-Reply-To: <284c81fa-8abc-a53d-7905-c962089c64a0@apache.org> References: <284c81fa-8abc-a53d-7905-c962089c64a0@apache.org> From: James Taylor Date: Fri, 13 Oct 2017 14:40:23 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [DISCUSS] Road to HBase 2.0.0 To: "dev@phoenix.apache.org" Cc: Anoop John Content-Type: multipart/alternative; boundary="94eb2c06f3401eacd1055b7481e1" archived-at: Fri, 13 Oct 2017 21:40:27 -0000 --94eb2c06f3401eacd1055b7481e1 Content-Type: text/plain; charset="UTF-8" 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 >>> >> --94eb2c06f3401eacd1055b7481e1--