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 B218B200CCC for ; Fri, 21 Jul 2017 18:03:57 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id B087C16D27B; Fri, 21 Jul 2017 16:03:57 +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 A91A716D1CF for ; Fri, 21 Jul 2017 18:03:56 +0200 (CEST) Received: (qmail 18197 invoked by uid 500); 21 Jul 2017 16:03:53 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 18185 invoked by uid 99); 21 Jul 2017 16:03:53 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Jul 2017 16:03:53 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id DB367180256 for ; Fri, 21 Jul 2017 16:03:52 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.48 X-Spam-Level: ** X-Spam-Status: No, score=2.48 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id cWfNNcWoXcyf for ; Fri, 21 Jul 2017 16:03:48 +0000 (UTC) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id A7B555FD33 for ; Fri, 21 Jul 2017 16:03:48 +0000 (UTC) Received: by mail-yw0-f171.google.com with SMTP id x125so26372707ywa.0 for ; Fri, 21 Jul 2017 09:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=o4qU9f3hBgJJLR1+AHsTJwmwOgCHCmi3YRPZGYnX244=; b=Yd5buxbK+zXKDMefWXU0uWL5DP6ML2hRl2yLFI50TJ3D17I+wPaXJtVMLoAxHOGhrM AeA0LsX+lccwJXUPoZtfpBcO7xFI9YdeOrHNISArxGhDyKBRinaxzEP61zRpBoncRof4 UrVUmiLppmW3iqEPUa9rwhO71bo9aI1g3Y6ysyw5gxjhqpGAdKRPv2pBpnIV/itdjVdJ KVAcGub+TkQIGDiH2FISnZuDk+5MDWV3pXR8R8AViNXie/p22IGkn11vTM6QaBOmLsVd 2jCOEzKVpEbvZ3m17/YRTbOWgibHK2BpgXLSn2Avz1TXqJEHkcxekd9PqswebYlnoRXk Ozqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=o4qU9f3hBgJJLR1+AHsTJwmwOgCHCmi3YRPZGYnX244=; b=BJB2VA/ca6yVllhHZSgT5qXcXg6B1lYVYe3jU6/l207fNFN+KhaOer3UooVVXZ3cx4 h6Fu4JCPtirENIf1S3Gw1vQ9mEpyAUqLaj+Y/+mKDEG8DYdnnZScsSByJbSL+wF2dyta VfWgI+xxC8iS8Sl+CYYkr0EawqQpklcsn2QB8F7MfYdRjUTUiXsdWJenoACZhofSZslS YpxczDdakpx2ZgfPniWO9IhPEONq8NwSyuvMZyXEQrU3FW6XYwDuaULcsd7HjnrlvMfT UQjssmGKF3EtXYZCYqNTGlnMBv5vuiXIkEtNIw6sHmnxKrvYeU3iUPYNUrePGJD95lWY jKTQ== X-Gm-Message-State: AIVw112uyjBiHlo3nUQocJUTtfwOln5kwWoud1hiFVRuodzV4S6KKfIm PW8ot5a6G8IQVNu6BtxiqQ2urOEIiRmifVc= X-Received: by 10.129.98.6 with SMTP id w6mr6406214ywb.29.1500653027519; Fri, 21 Jul 2017 09:03:47 -0700 (PDT) MIME-Version: 1.0 Sender: saint.ack@gmail.com Received: by 10.37.69.132 with HTTP; Fri, 21 Jul 2017 09:03:46 -0700 (PDT) In-Reply-To: References: <64DC0B0F-E4F4-4057-B6D4-99F1AB870D19@gmail.com> <10AF22C1-E962-41C4-9AC4-CDD48732B675@gmail.com> <90291ea3-935e-b0bd-4053-a4e2494b733c@apache.org> <1708072065.5042071.1484705475111@mail.yahoo.com> <358199494.84630.1484778398192@mail.yahoo.com> <74F23C0E-AB0B-468E-81C9-92B3058A2753@gmail.com> <58BF2B62.203@apache.org> <58C4A522.4080502@apache.org> From: Stack Date: Fri, 21 Jul 2017 17:03:46 +0100 X-Google-Sender-Auth: g8q1tqbsZ9CVGvoJfsAQL4nMNy4 Message-ID: Subject: Re: Moving 2.0 forward To: HBase Dev List Content-Type: multipart/alternative; boundary="001a114705aaa30a620554d6027a" archived-at: Fri, 21 Jul 2017 16:03:57 -0000 --001a114705aaa30a620554d6027a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Status update girls and boys! hbase-2.0.0-alpha1 went out June 22nd. alpha2 has been a bit slow to follow (holidays) though there has been steady progress closing out blockers and criticals by a bunch of you all. The plan is for a release in the first week or so of August. It should be fully up on hbase-thirdparty using updated (and relocated) versions of netty, guava, and protobuf as well as a default deploy that has master-carrying-no-regions. alpha3 will follow soon after and will focus on making sure our user-facing APIs are clean (branch-1 compatible, no illicit removals/mods, and so on) and that basic upgrade 'works'. betas start in September? I've been keeping a rough general state here [1] (please update any section that is lagging actuality) but for details on what blockers and criticals remain, see the JIRA 2.0 view [2]. Recent issue-gardening has brought 2.0 into better focus. Feel free to review and punt items you think can wait till 3.0 or 2.1. If you want to pull in more stuff, please ask first. Thanks, St.Ack 1. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_ktczrlKHK8N4= SZzs/edit# 2. https://issues.apache.org/jira/projects/HBASE/versions/12327188 On Mon, May 15, 2017 at 4:05 PM, Stack wrote: > > On Mon, May 15, 2017 at 1:46 AM, =E5=BC=A0=E9=93=8E(Duo Zhang) > wrote: > >> HBASE-18037 is a new blocker. I'm currently working on it, will be >> finished >> soon I think. >> >> I made it a blocker then and added it to our hbase2 release doc [1] list > as a blocker. > > Thanks, > St.Ack > > 1. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_ > ktczrlKHK8N4SZzs/edit# > > >> 2017-05-15 14:12 GMT+08:00 Stack : >> >> >> > A month on. Status. >> > >> > I've been working on the HBASE-14614 branch cluster testing. After a >> load >> > of fixing, the branch passes smaller test runs (an hour or so of ITBLL >> up >> > to 2B rows w/ killing monkeys). When I go larger, to a scale I've not >> done >> > in a while, I start to run into other interesting issues -- some of >> which >> > are related to AMv2 (I'm fixing), but others are not (100G WALs that >> take >> > ten minutes to split makes for interesting cascades when monkeys kill >> > inside the ten minutes...). I intend to keep on with this larger scale >> > testing since it is uncovering good stuff (especially when HDFS is dog >> slow >> > because of background replications) but my thinking is that I should b= e >> > large scale testing branch-2, not just HBASE-14614. I think HBASE-1461= 4, >> > the new AMv2, is good enough to merge to master these times. Given it = is >> > the last blocker, once in, I'll cut the hbase2 branch. >> > >> > I'll start up a 'Merge HBASE-14614' DISCUSSION thread in the next day >> or so >> > (I need to fix some unit tests...). >> > >> > The AMv2 doc is still a work in progress but should give a gist on >> where we >> > are currently[1]. There is a bunch of todo still but seems tractable; >> e.g. >> > rolling upgrade, finish doc., and we don't have an HBCK since it needs >> to >> > be recast in light of how stuff now works but a redo on HBCK is >> premature >> > given we don't know failure types as yet (we just fix the problems as >> they >> > come up). >> > >> > St.Ack >> > 1. >> > https://docs.google.com/document/d/1eVKa7FHdeoJ1- >> > 9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit# >> > >> > >> > >> > On Thu, Apr 13, 2017 at 1:43 PM, Stack wrote: >> > >> > > Some status: >> > > >> > > AMv2 (HBASE-14614) is near to passing all tests caveat my disabling = of >> > all >> > > to-do w/ fsck (fsck needs revamp) and tests that expect that they ca= n >> > move >> > > hbase;meta off master (AMv2 enforces this constraint; it is supposed >> to >> > be >> > > enforced on AMv1 but meta-on-master is incompletely realized in AMv1 >> and >> > > AMv2). A few other tests have been disabled for various reasons. See >> [1] >> > > for full list. >> > > >> > > There is a hefty list of TODOs still (Again see the messy doc [1]) b= ut >> > the >> > > only 'blocker', IMO, is community confidence in AMv2. Currently, >> cluster >> > > tests with chaos fail (new form of 'stuck' regions). Takes time >> > > investigating. >> > > >> > > Will keep you all posted. >> > > St.Ack >> > > >> > > >> > > >> > > 1. https://docs.google.com/document/d/1eVKa7FHdeoJ1- >> > > 9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=3Dh.92vclum0bvod >> > > >> > > >> > > >> > > On Fri, Mar 31, 2017 at 1:14 PM, Andrew Purtell >> > > wrote: >> > > >> > >> +1 on branching (yay!) >> > >> >> > >> I have EC2 resources for running ITBLL etc. >> > >> >> > >> >> > >> On Thu, Mar 30, 2017 at 5:07 PM, Stack wrote: >> > >> >> > >> > Some notes on progress toward hbase2. >> > >> > >> > >> > Given that stability and performance are NOT emergent behaviors b= ut >> > >> rather >> > >> > projects unto themselves, my thought is that we commit all that >> we've >> > >> > agreed as core for hbase2 (see [1]), branch, and then work on >> > >> stabilizing >> > >> > and perf rather than do stabilize, commit, and then branch. What >> this >> > >> means >> > >> > in practice is that for features like Inmemory Compaction, we >> commit >> > it >> > >> > defaulted 'on' ("BASIC" mode) which is what we want in hbase2. >> Should >> > it >> > >> > prove problematic under test, we disable it before release. >> > >> > >> > >> > Are folks good w/ this mode? I ask because, in a few issues there >> are >> > >> > requests for proof that a master feature is 'stable' before commi= t. >> > >> This is >> > >> > normally a healthy request only in master's case, it is hard to >> > >> demonstrate >> > >> > stability given its current state. >> > >> > >> > >> > Other outstanding issues such as decisions about whether master >> hosts >> > >> > system tables only (by default), I'm thinking, we can work out po= st >> > >> branch >> > >> > in alpha/betas before release. >> > >> > >> > >> > The awkward item is the long-pole Assignment Manager. This is an >> > >> > all-or-nothing affair. Here we are switching in a new Master core= . >> > >> While I >> > >> > think it fine that AMv2 is incomplete come branch time, those of = us >> > >> working >> > >> > on the new AM still need to demonstrate to you all that it >> basically >> > >> > viable. >> > >> > >> > >> > The point-of-no-return is commit of the patch in HBASE-14614. >> > >> HBASE-14614 >> > >> > (AMv2) is coming close to passing all unit tests. We'll spend som= e >> > time >> > >> > running it on a cluster to make sure it fundamentally sound and >> will >> > >> report >> > >> > back on our experience. There has been an ask for some dev doc an= d >> > >> > low-levels on how it works (in progress). Let satisfaction of the= se >> > >> > requests be blockers on commit. We'll put the HBASE-14614 commit = up >> > for >> > >> a >> > >> > vote on dev list given its import. >> > >> > >> > >> > Branch will happen after HBASE-14614 goes in (or its rejection) >> with >> > our >> > >> > first alpha soon after. Its looking like a week or two at least >> given >> > >> how >> > >> > things have been going up to this. >> > >> > >> > >> > I intend to start in on hbase2 stability/perf projects after we >> > branch. >> > >> > >> > >> > Interested in any thoughts you all might have on the above (Would >> also >> > >> > appreciate updates on state in [1] if you are a feature owner). >> > >> > >> > >> > Thanks, >> > >> > St.Ack >> > >> > >> > >> > 1. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4 >> > >> > z9iEu_ktczrlKHK8N4SZzs/edit# >> > >> > >> > >> > >> > >> > >> > >> > On Sat, Mar 11, 2017 at 5:32 PM, Josh Elser >> > wrote: >> > >> > >> > >> > > >> > >> > > Stack wrote: >> > >> > > >> > >> > >> On Tue, Mar 7, 2017 at 1:51 PM, Josh Elser >> > >> wrote: >> > >> > >> >> > >> > >> Thanks for pulling in the FS Quotas work, Stack. I'm trying to >> > cross >> > >> the >> > >> > >>> last T's and dot the last I's. >> > >> > >>> >> > >> > >>> The biggest thing I know I need to do still is to write a new >> > >> chapter >> > >> > to >> > >> > >>> the book. After that, I'd start entertaining larger >> > >> reviews/discussions >> > >> > >>> to >> > >> > >>> merge the feature into master. Anyone with free time (giggles= ) >> is >> > >> more >> > >> > >>> than >> > >> > >>> welcome to start perusing :) >> > >> > >>> >> > >> > >>> >> > >> > >>> Out of interest, this could come in after 2.0 Josh? Any 2.0 >> > specific >> > >> > >> needs >> > >> > >> to make this work? >> > >> > >> >> > >> > >> Meantime, updated the 2.0 doc 1. >> > >> > >> >> > >> > >> Thanks Josh, >> > >> > >> St.Ack >> > >> > >> >> > >> > >> 1. >> > >> > >> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9i >> > >> > >> Eu_ktczrlKHK8N4SZzs/edit# >> > >> > >> >> > >> > >> >> > >> > > Nope, no need to block 2.0 on this one (given the other, relate= d >> > >> > chatter). >> > >> > > Would be nice to get it in, but I completely understand if it >> slips >> > :) >> > >> > > >> > >> > > Thanks for updating the doc for me! >> > >> > > >> > >> > >> > >> >> > >> >> > >> >> > >> -- >> > >> Best regards, >> > >> >> > >> - Andy >> > >> >> > >> If you are given a choice, you believe you have acted freely. - >> Raymond >> > >> Teller (via Peter Watts) >> > >> >> > > >> > > >> > >> > > --001a114705aaa30a620554d6027a--