Re: [VOTE] The first hbase-2.0.0-beta-2 Release Candidate is available for download

[Mike Drob]

+0, I didn't have enough time on this RC to run a more complete suite of
tests like I was hoping for.

sign/sums ok
SHOULD NOT supply a MD5 checksum file (because MD5 is too broken). [1]

compile src 8u151 ok
compile src 8u151 w/ error-prone NOT OK - HBASE-19987

[1]: http://www.apache.org/dev/release-distribution#sigs-and-sums



On Fri, Mar 2, 2018 at 5:40 PM, Stack  wrote:

> The first release candidate for HBase 2.0.0-beta-2 is up at
>
>  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0-beta-2.RC0/
>
> Maven artifacts are available from a staging directory here:
>
>   https://repository.apache.org/content/repositories/orgapachehbase-1199
>
> All was signed with my key at 8ACC93D2 [1]
>
> I tagged the RC as 2.0.0-beta-2RC0.2 at
> 9e9b347d667e1fc6165c9f8ae5ae7052147e8895
>
> hbase-2.0.0-beta-2 is a not-for-production preview of hbase-2.0.0. It is
> meant for devs and downstreamers to test drive and flag us if we messed up
> on anything ahead of our rolling
> actual 2.0.0 release candidates ("GAs").
>
> hbase-2.0.0-beta-2 is our second beta release. More than 200 fixes have
> gone in since
> beta-1. Unit tests generallly pass when run against hadoop2 and hadoop3[5].
> It includes
> all that was in previous alphas and beta (new assignment manager, offheap
> read/write
> path, in-memory compactions, etc).The list of features addressed in 2.0.0
> so far can be
> found here [3]. There are thousands. The list of ~3k+ fixes in 2.0.0
> exclusively can be
> found here [4]. Our overview doc. on the state of 2.0.0 is at [6].
>
> This beta was supposed to have as its focus rolling upgrade from hbase-1.x
> versions but
> this is work not complete (At this late stage, it is looking like it will
> be a post-2.0.0 project).
>
> This is our last hbase-2.0.0 beta release. Next up, we'll be rolling an
> actual 2.0.0 release
> candidate. Look for this in a week or two after beta-2 goes out, after
> we've done more
> testing and documentation (and we fix issues raised by you all against this
> beta).
>
> One known issue, still unaddressed, is that the User API has not been
> properly filtered
> so it shows more than just InterfaceAudience Public content (HBASE-19663,
> to be fixed
> by release).
>
> Please take this beta for a spin. Please vote on whether it ok to put out
> this RC as our second
> beta (Note CHANGES has not yet been updated). Let the VOTE be open for at
> least 72 hours
> (Lets say Wednesday morning, March 7th).
>
> Thanks,
> Your 2.0.0 Release Manager
>
> 1. http://pgp.mit.edu/pks/lookup?op=get=0x9816C7FC8ACC93D2
> 3. https://goo.gl/scYjJr
> 4. https://goo.gl/dFFT8b
> 5. https://builds.apache.org/job/HBase%20Nightly/job/branch-2/
> 
> 6. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4
> z9iEu_ktczrlKHK8N4SZzs/
>

Re: [NOTICE] branch-2 open for commits again but please get my ok before commit; thanks.

[Stack]

After release, hopefully in morning. Thanks for reminder.
S

On Tue, Mar 6, 2018 at 4:48 PM, 张铎(Duo Zhang)  wrote:

> So is it the time to cut branch-2.0?
>
> 2018-03-07 8:04 GMT+08:00 Stack :
>
> > On Tue, Mar 6, 2018 at 10:32 AM, Sean Busbey  wrote:
> >
> > > Is branch-2 open again now? Sorry if I missed the all-clear but I
> > > could not find it.
> > >
> > >
> > I hadn't sent one.
> >
> > Was nervous watching my nightlies:
> > https://builds.apache.org/job/HBase%20Nightly/job/branch-2/
> >
> > Let me open it again.
> >
> > Please ping me before committing on branch-2. Trying to keep the ship
> > upright.
> >
> > Thanks for your patience,
> >
> > St.Ack
> >
> >
> >
> >
> > > On Thu, Mar 1, 2018 at 11:59 AM, Stack  wrote:
> > > > Short Version: Please hold on making commits to branch-2. I am in the
> > > > process of cutting a hbase-2.0.0-beta-2 release candidate. It make
> take
> > > me
> > > > a day or so.
> > > >
> > > > Long Version:
> > > >
> > > > A miracle happened last night. Our nightly for branch-2 passed [1].
> > This
> > > > means all unit tests ran against hadoop2 and then subsequently, all
> > unit
> > > > tests ran against hadoop3. It had been threatening for a while. A few
> > > > recent builds passed all unit tests only to fail on a few findbugs
> > > issues.
> > > >
> > > > Given this momentous event and that there are over 200 fixes since
> > > beta-1,
> > > > it is time to push out a beta-2.
> > > >
> > > > Originally beta-2 was supposed to be about making sure we could do a
> > > > rolling upgrade from branch-1 to branch-2. This was its theme. The
> work
> > > has
> > > > not been done. Also, a bunch of work is still to be done around
> > testing,
> > > > compatibility checking, and performance. Perhaps folks are waiting on
> > the
> > > > 2.0.0 release candidate before they dig in (smile)?
> > > >
> > > > I'll give the all clear once I've cut my release. Thank you for your
> > > > patience.
> > > > St.Ack
> > > >
> > > >
> > > > 1. See build #415 here
> > > > https://builds.apache.org/job/HBase%20Nightly/job/branch-2/
> > >
> >
>

Re: [VOTE] The first hbase-2.0.0-beta-2 Release Candidate is available for download

[Jean-Marc Spaggiari]

I deployed it on 8 nodes, running many different things including MR,
RowCounts, compactions, etc. Nothing new. So far so good...

2018-03-06 17:29 GMT-05:00 Stack :

> On Tue, Mar 6, 2018 at 12:52 PM, Peter Somogyi 
> wrote:
>
> > +1 (non-binding)
> >
> > - Signature, checksum OK
> > - Test suite using 1.8.0_161 OK
> > - Build and run from source OK
> > - Run from bin tarball OK
> > - PE 1M rows OK
> > - LTT 1M rows OK
> > - Basic operations from shell and Java client OK
> >
> > One thing I noticed: CHANGES.txt isn't updated, latest information is
> about
> > 0.93.0 - Unreleased. The 1.4.2 release contains up-to-date CHANGES.txt.
> > Will the CHANGES.txt be updated only for the final 2.0.0 release?
> >
> > Thanks Peter for trying the RC. Yeah, CHANGES.txt needs to be up-to-date
> by RC (I tried to note that this had not been done in the head of this
> thread 'Note CHANGES has not yet been updated').
>
> S
>
>
>
> >
> > On Tue, Mar 6, 2018 at 10:58 AM, Artem Ervits 
> > wrote:
> >
> > > +1 (non-binding)
> > >
> > > Hadoop Pseudo-distrbibuted: 2.7.5
> > > $M2_HOME from scratch
> > > Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> > > 2017-10-18T07:58:13Z)
> > > Maven home: /opt/maven/apache-maven-3.5.2
> > > Java version: 1.8.0_161, vendor: Oracle Corporation
> > > Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.
> > > x86_64/jre
> > > Default locale: en_US, platform encoding: UTF-8
> > > OS name: "linux", version: "3.10.0-693.11.6.el7.x86_64", arch: "amd64",
> > > family: "unix"
> > >
> > > Binary Release:
> > > Java 1M rows: OK
> > > LTT 1M rows: OK
> > > PE 1M rows: OK
> > > MD5: OK
> > >
> > > hbase shell: OK
> > > create, list, scan, count, truncate, disable, drop
> > > snapshot, restore_snapshot
> > > UI:
> > >   split: OK
> > >   merge: OK
> > >
> > > Source Release:
> > > Build with: mvn clean -DskipTests -Dhadoop-two.version=2.7.5
> > > install && mvn clean -DskipTests -Dhadoop-two.version=2.7.5 package
> > > assembly:single   OK
> > > MD5: OK
> > > installed and ran from src: OK
> > >
> > > mvn test -P runSmallTests: NOK (this can be my own environment and I've
> > > surfaced this in votes for 1.4.1 and 1.4.2 but failing class is the
> same
> > > but failure is different.
> > >
> > >   [ESC[1;34mINFOESC[m] Results:
> > > [ESC[1;34mINFOESC[m]
> > > [ESC[1;31mERRORESC[m] ESC[1;31mFailures: ESC[m
> > > [ESC[1;31mERRORESC[m] ESC[1;31m
> > > TestSpnegoHttpServer.testAllowedClient:243->Assert.
> > > assertEquals:631->Assert.assertEquals:645->Assert.
> > > failNotEquals:834->Assert.fail:88
> > > expected:<200> but was:<401>ESC[m
> > > [ESC[1;34mINFOESC[m]
> > >
> > > On Tue, Mar 6, 2018 at 10:57 AM, Josh Elser  wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > * src release OK
> > > > * xsums/sigs OK
> > > > * Can build and run from src OK
> > > > * Loaded some data locally
> > > >
> > > >
> > > > On 3/2/18 6:40 PM, Stack wrote:
> > > >
> > > >> The first release candidate for HBase 2.0.0-beta-2 is up at
> > > >>
> > > >>   https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0-
> > beta-2.RC0/
> > > >>
> > > >> Maven artifacts are available from a staging directory here:
> > > >>
> > > >>https://repository.apache.org/content/repositories/
> > > orgapachehbase-1199
> > > >>
> > > >> All was signed with my key at 8ACC93D2 [1]
> > > >>
> > > >> I tagged the RC as 2.0.0-beta-2RC0.2 at
> > > >> 9e9b347d667e1fc6165c9f8ae5ae7052147e8895
> > > >>
> > > >> hbase-2.0.0-beta-2 is a not-for-production preview of hbase-2.0.0.
> It
> > is
> > > >> meant for devs and downstreamers to test drive and flag us if we
> > messed
> > > up
> > > >> on anything ahead of our rolling
> > > >> actual 2.0.0 release candidates ("GAs").
> > > >>
> > > >> hbase-2.0.0-beta-2 is our second beta release. More than 200 fixes
> > have
> > > >> gone in since
> > > >> beta-1. Unit tests generallly pass when run against hadoop2 and
> > > >> hadoop3[5].
> > > >> It includes
> > > >> all that was in previous alphas and beta (new assignment manager,
> > > offheap
> > > >> read/write
> > > >> path, in-memory compactions, etc).The list of features addressed in
> > > 2.0.0
> > > >> so far can be
> > > >> found here [3]. There are thousands. The list of ~3k+ fixes in 2.0.0
> > > >> exclusively can be
> > > >> found here [4]. Our overview doc. on the state of 2.0.0 is at [6].
> > > >>
> > > >> This beta was supposed to have as its focus rolling upgrade from
> > > hbase-1.x
> > > >> versions but
> > > >> this is work not complete (At this late stage, it is looking like it
> > > will
> > > >> be a post-2.0.0 project).
> > > >>
> > > >> This is our last hbase-2.0.0 beta release. Next up, we'll be rolling
> > an
> > > >> actual 2.0.0 release
> > > >> candidate. Look for this in a week or two after beta-2 goes out,
> after
> > > >> we've done more
> > > >> testing and documentation (and we fix issues raised by you all
> against

Re: [NOTICE] branch-2 open for commits again but please get my ok before commit; thanks.

[Duo Zhang]

So is it the time to cut branch-2.0?

2018-03-07 8:04 GMT+08:00 Stack :

> On Tue, Mar 6, 2018 at 10:32 AM, Sean Busbey  wrote:
>
> > Is branch-2 open again now? Sorry if I missed the all-clear but I
> > could not find it.
> >
> >
> I hadn't sent one.
>
> Was nervous watching my nightlies:
> https://builds.apache.org/job/HBase%20Nightly/job/branch-2/
>
> Let me open it again.
>
> Please ping me before committing on branch-2. Trying to keep the ship
> upright.
>
> Thanks for your patience,
>
> St.Ack
>
>
>
>
> > On Thu, Mar 1, 2018 at 11:59 AM, Stack  wrote:
> > > Short Version: Please hold on making commits to branch-2. I am in the
> > > process of cutting a hbase-2.0.0-beta-2 release candidate. It make take
> > me
> > > a day or so.
> > >
> > > Long Version:
> > >
> > > A miracle happened last night. Our nightly for branch-2 passed [1].
> This
> > > means all unit tests ran against hadoop2 and then subsequently, all
> unit
> > > tests ran against hadoop3. It had been threatening for a while. A few
> > > recent builds passed all unit tests only to fail on a few findbugs
> > issues.
> > >
> > > Given this momentous event and that there are over 200 fixes since
> > beta-1,
> > > it is time to push out a beta-2.
> > >
> > > Originally beta-2 was supposed to be about making sure we could do a
> > > rolling upgrade from branch-1 to branch-2. This was its theme. The work
> > has
> > > not been done. Also, a bunch of work is still to be done around
> testing,
> > > compatibility checking, and performance. Perhaps folks are waiting on
> the
> > > 2.0.0 release candidate before they dig in (smile)?
> > >
> > > I'll give the all clear once I've cut my release. Thank you for your
> > > patience.
> > > St.Ack
> > >
> > >
> > > 1. See build #415 here
> > > https://builds.apache.org/job/HBase%20Nightly/job/branch-2/
> >
>

[NOTICE] branch-2 open for commits again but please get my ok before commit; thanks.

[Stack]

On Tue, Mar 6, 2018 at 10:32 AM, Sean Busbey  wrote:

> Is branch-2 open again now? Sorry if I missed the all-clear but I
> could not find it.
>
>
I hadn't sent one.

Was nervous watching my nightlies:
https://builds.apache.org/job/HBase%20Nightly/job/branch-2/

Let me open it again.

Please ping me before committing on branch-2. Trying to keep the ship
upright.

Thanks for your patience,

St.Ack




> On Thu, Mar 1, 2018 at 11:59 AM, Stack  wrote:
> > Short Version: Please hold on making commits to branch-2. I am in the
> > process of cutting a hbase-2.0.0-beta-2 release candidate. It make take
> me
> > a day or so.
> >
> > Long Version:
> >
> > A miracle happened last night. Our nightly for branch-2 passed [1]. This
> > means all unit tests ran against hadoop2 and then subsequently, all unit
> > tests ran against hadoop3. It had been threatening for a while. A few
> > recent builds passed all unit tests only to fail on a few findbugs
> issues.
> >
> > Given this momentous event and that there are over 200 fixes since
> beta-1,
> > it is time to push out a beta-2.
> >
> > Originally beta-2 was supposed to be about making sure we could do a
> > rolling upgrade from branch-1 to branch-2. This was its theme. The work
> has
> > not been done. Also, a bunch of work is still to be done around testing,
> > compatibility checking, and performance. Perhaps folks are waiting on the
> > 2.0.0 release candidate before they dig in (smile)?
> >
> > I'll give the all clear once I've cut my release. Thank you for your
> > patience.
> > St.Ack
> >
> >
> > 1. See build #415 here
> > https://builds.apache.org/job/HBase%20Nightly/job/branch-2/
>

Re: [VOTE] The first hbase-2.0.0-beta-2 Release Candidate is available for download

[Stack]

On Tue, Mar 6, 2018 at 12:52 PM, Peter Somogyi  wrote:

> +1 (non-binding)
>
> - Signature, checksum OK
> - Test suite using 1.8.0_161 OK
> - Build and run from source OK
> - Run from bin tarball OK
> - PE 1M rows OK
> - LTT 1M rows OK
> - Basic operations from shell and Java client OK
>
> One thing I noticed: CHANGES.txt isn't updated, latest information is about
> 0.93.0 - Unreleased. The 1.4.2 release contains up-to-date CHANGES.txt.
> Will the CHANGES.txt be updated only for the final 2.0.0 release?
>
> Thanks Peter for trying the RC. Yeah, CHANGES.txt needs to be up-to-date
by RC (I tried to note that this had not been done in the head of this
thread 'Note CHANGES has not yet been updated').

S



>
> On Tue, Mar 6, 2018 at 10:58 AM, Artem Ervits 
> wrote:
>
> > +1 (non-binding)
> >
> > Hadoop Pseudo-distrbibuted: 2.7.5
> > $M2_HOME from scratch
> > Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> > 2017-10-18T07:58:13Z)
> > Maven home: /opt/maven/apache-maven-3.5.2
> > Java version: 1.8.0_161, vendor: Oracle Corporation
> > Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.
> > x86_64/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "3.10.0-693.11.6.el7.x86_64", arch: "amd64",
> > family: "unix"
> >
> > Binary Release:
> > Java 1M rows: OK
> > LTT 1M rows: OK
> > PE 1M rows: OK
> > MD5: OK
> >
> > hbase shell: OK
> > create, list, scan, count, truncate, disable, drop
> > snapshot, restore_snapshot
> > UI:
> >   split: OK
> >   merge: OK
> >
> > Source Release:
> > Build with: mvn clean -DskipTests -Dhadoop-two.version=2.7.5
> > install && mvn clean -DskipTests -Dhadoop-two.version=2.7.5 package
> > assembly:single   OK
> > MD5: OK
> > installed and ran from src: OK
> >
> > mvn test -P runSmallTests: NOK (this can be my own environment and I've
> > surfaced this in votes for 1.4.1 and 1.4.2 but failing class is the same
> > but failure is different.
> >
> >   [ESC[1;34mINFOESC[m] Results:
> > [ESC[1;34mINFOESC[m]
> > [ESC[1;31mERRORESC[m] ESC[1;31mFailures: ESC[m
> > [ESC[1;31mERRORESC[m] ESC[1;31m
> > TestSpnegoHttpServer.testAllowedClient:243->Assert.
> > assertEquals:631->Assert.assertEquals:645->Assert.
> > failNotEquals:834->Assert.fail:88
> > expected:<200> but was:<401>ESC[m
> > [ESC[1;34mINFOESC[m]
> >
> > On Tue, Mar 6, 2018 at 10:57 AM, Josh Elser  wrote:
> >
> > > +1 (binding)
> > >
> > > * src release OK
> > > * xsums/sigs OK
> > > * Can build and run from src OK
> > > * Loaded some data locally
> > >
> > >
> > > On 3/2/18 6:40 PM, Stack wrote:
> > >
> > >> The first release candidate for HBase 2.0.0-beta-2 is up at
> > >>
> > >>   https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0-
> beta-2.RC0/
> > >>
> > >> Maven artifacts are available from a staging directory here:
> > >>
> > >>https://repository.apache.org/content/repositories/
> > orgapachehbase-1199
> > >>
> > >> All was signed with my key at 8ACC93D2 [1]
> > >>
> > >> I tagged the RC as 2.0.0-beta-2RC0.2 at
> > >> 9e9b347d667e1fc6165c9f8ae5ae7052147e8895
> > >>
> > >> hbase-2.0.0-beta-2 is a not-for-production preview of hbase-2.0.0. It
> is
> > >> meant for devs and downstreamers to test drive and flag us if we
> messed
> > up
> > >> on anything ahead of our rolling
> > >> actual 2.0.0 release candidates ("GAs").
> > >>
> > >> hbase-2.0.0-beta-2 is our second beta release. More than 200 fixes
> have
> > >> gone in since
> > >> beta-1. Unit tests generallly pass when run against hadoop2 and
> > >> hadoop3[5].
> > >> It includes
> > >> all that was in previous alphas and beta (new assignment manager,
> > offheap
> > >> read/write
> > >> path, in-memory compactions, etc).The list of features addressed in
> > 2.0.0
> > >> so far can be
> > >> found here [3]. There are thousands. The list of ~3k+ fixes in 2.0.0
> > >> exclusively can be
> > >> found here [4]. Our overview doc. on the state of 2.0.0 is at [6].
> > >>
> > >> This beta was supposed to have as its focus rolling upgrade from
> > hbase-1.x
> > >> versions but
> > >> this is work not complete (At this late stage, it is looking like it
> > will
> > >> be a post-2.0.0 project).
> > >>
> > >> This is our last hbase-2.0.0 beta release. Next up, we'll be rolling
> an
> > >> actual 2.0.0 release
> > >> candidate. Look for this in a week or two after beta-2 goes out, after
> > >> we've done more
> > >> testing and documentation (and we fix issues raised by you all against
> > >> this
> > >> beta).
> > >>
> > >> One known issue, still unaddressed, is that the User API has not been
> > >> properly filtered
> > >> so it shows more than just InterfaceAudience Public content
> > (HBASE-19663,
> > >> to be fixed
> > >> by release).
> > >>
> > >> Please take this beta for a spin. Please vote on whether it ok to put
> > out
> > >> this RC as our second
> > >> beta (Note CHANGES has not yet been updated). Let the VOTE be open for
> > at
> > >> 

[jira] [Created] (HBASE-20143) Fix checkstyle introduced in parent in new test additions

[stack (JIRA)]

stack created HBASE-20143:
-

 Summary: Fix checkstyle introduced in parent in new test additions
 Key: HBASE-20143
 URL: https://issues.apache.org/jira/browse/HBASE-20143
 Project: HBase
  Issue Type: Sub-task
Reporter: stack






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] The first hbase-2.0.0-beta-2 Release Candidate is available for download

[Peter Somogyi]

+1 (non-binding)

- Signature, checksum OK
- Test suite using 1.8.0_161 OK
- Build and run from source OK
- Run from bin tarball OK
- PE 1M rows OK
- LTT 1M rows OK
- Basic operations from shell and Java client OK

One thing I noticed: CHANGES.txt isn't updated, latest information is about
0.93.0 - Unreleased. The 1.4.2 release contains up-to-date CHANGES.txt.
Will the CHANGES.txt be updated only for the final 2.0.0 release?


On Tue, Mar 6, 2018 at 10:58 AM, Artem Ervits  wrote:

> +1 (non-binding)
>
> Hadoop Pseudo-distrbibuted: 2.7.5
> $M2_HOME from scratch
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T07:58:13Z)
> Maven home: /opt/maven/apache-maven-3.5.2
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.
> x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.11.6.el7.x86_64", arch: "amd64",
> family: "unix"
>
> Binary Release:
> Java 1M rows: OK
> LTT 1M rows: OK
> PE 1M rows: OK
> MD5: OK
>
> hbase shell: OK
> create, list, scan, count, truncate, disable, drop
> snapshot, restore_snapshot
> UI:
>   split: OK
>   merge: OK
>
> Source Release:
> Build with: mvn clean -DskipTests -Dhadoop-two.version=2.7.5
> install && mvn clean -DskipTests -Dhadoop-two.version=2.7.5 package
> assembly:single   OK
> MD5: OK
> installed and ran from src: OK
>
> mvn test -P runSmallTests: NOK (this can be my own environment and I've
> surfaced this in votes for 1.4.1 and 1.4.2 but failing class is the same
> but failure is different.
>
>   [ESC[1;34mINFOESC[m] Results:
> [ESC[1;34mINFOESC[m]
> [ESC[1;31mERRORESC[m] ESC[1;31mFailures: ESC[m
> [ESC[1;31mERRORESC[m] ESC[1;31m
> TestSpnegoHttpServer.testAllowedClient:243->Assert.
> assertEquals:631->Assert.assertEquals:645->Assert.
> failNotEquals:834->Assert.fail:88
> expected:<200> but was:<401>ESC[m
> [ESC[1;34mINFOESC[m]
>
> On Tue, Mar 6, 2018 at 10:57 AM, Josh Elser  wrote:
>
> > +1 (binding)
> >
> > * src release OK
> > * xsums/sigs OK
> > * Can build and run from src OK
> > * Loaded some data locally
> >
> >
> > On 3/2/18 6:40 PM, Stack wrote:
> >
> >> The first release candidate for HBase 2.0.0-beta-2 is up at
> >>
> >>   https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0-beta-2.RC0/
> >>
> >> Maven artifacts are available from a staging directory here:
> >>
> >>https://repository.apache.org/content/repositories/
> orgapachehbase-1199
> >>
> >> All was signed with my key at 8ACC93D2 [1]
> >>
> >> I tagged the RC as 2.0.0-beta-2RC0.2 at
> >> 9e9b347d667e1fc6165c9f8ae5ae7052147e8895
> >>
> >> hbase-2.0.0-beta-2 is a not-for-production preview of hbase-2.0.0. It is
> >> meant for devs and downstreamers to test drive and flag us if we messed
> up
> >> on anything ahead of our rolling
> >> actual 2.0.0 release candidates ("GAs").
> >>
> >> hbase-2.0.0-beta-2 is our second beta release. More than 200 fixes have
> >> gone in since
> >> beta-1. Unit tests generallly pass when run against hadoop2 and
> >> hadoop3[5].
> >> It includes
> >> all that was in previous alphas and beta (new assignment manager,
> offheap
> >> read/write
> >> path, in-memory compactions, etc).The list of features addressed in
> 2.0.0
> >> so far can be
> >> found here [3]. There are thousands. The list of ~3k+ fixes in 2.0.0
> >> exclusively can be
> >> found here [4]. Our overview doc. on the state of 2.0.0 is at [6].
> >>
> >> This beta was supposed to have as its focus rolling upgrade from
> hbase-1.x
> >> versions but
> >> this is work not complete (At this late stage, it is looking like it
> will
> >> be a post-2.0.0 project).
> >>
> >> This is our last hbase-2.0.0 beta release. Next up, we'll be rolling an
> >> actual 2.0.0 release
> >> candidate. Look for this in a week or two after beta-2 goes out, after
> >> we've done more
> >> testing and documentation (and we fix issues raised by you all against
> >> this
> >> beta).
> >>
> >> One known issue, still unaddressed, is that the User API has not been
> >> properly filtered
> >> so it shows more than just InterfaceAudience Public content
> (HBASE-19663,
> >> to be fixed
> >> by release).
> >>
> >> Please take this beta for a spin. Please vote on whether it ok to put
> out
> >> this RC as our second
> >> beta (Note CHANGES has not yet been updated). Let the VOTE be open for
> at
> >> least 72 hours
> >> (Lets say Wednesday morning, March 7th).
> >>
> >> Thanks,
> >> Your 2.0.0 Release Manager
> >>
> >> 1. http://pgp.mit.edu/pks/lookup?op=get=0x9816C7FC8ACC93D2
> >> 3. https://goo.gl/scYjJr
> >> 4. https://goo.gl/dFFT8b
> >> 5. https://builds.apache.org/job/HBase%20Nightly/job/branch-2/
> >> 
> >> 6. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4
> >> z9iEu_ktczrlKHK8N4SZzs/
> >>
> >>
>

[jira] [Resolved] (HBASE-16795) Revisit 'in project Maven repo' checked in as part of HBASE-14785

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-16795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob resolved HBASE-16795.
---
Resolution: Won't Fix

Branch 1.1 is EOL

> Revisit 'in project Maven repo' checked in as part of HBASE-14785
> -
>
> Key: HBASE-16795
> URL: https://issues.apache.org/jira/browse/HBASE-16795
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.1.13
>Reporter: Andrew Purtell
>Priority: Major
>
> I did a naive update of docs on branch-1.1 from master like so:
> {noformat}
> $ git co master src
> ...
> {noformat}
> and the result failed a RAT check. Looking at rat.txt I noticed we are 
> including binaries in our source tarball, checked in as part of HBASE-14785. 
> {noformat}
> HBASE-14785 Addendum: Add an in-project Maven repo
>  src/main/site/resources/css/site.css |   1 -
>  .../maven-fluido-skin/1.5-HBASE/maven-fluido-skin-1.5-HBASE.jar  | Bin 0 -> 
> 344936 bytes
>  .../maven-fluido-skin/1.5-HBASE/maven-fluido-skin-1.5-HBASE.pom  | 718 
> 
>  .../maven/skins/maven-fluido-skin/maven-metadata-local.xml   |  12 +
>  4 files changed, 730 insertions(+), 1 deletion(-)
> {noformat}
> I'm not sure why RAT flagged this in that 1.1 build when I see that 
> previously we have copied back docs from master into the branch. Perhaps 
> previous copies have been more selective. 
> This change has been committed for over a year. Let's make sure we have 
> discussed this and determined it is appropriate. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-15168) Zombie stomping branch-1.1 edition

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-15168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob resolved HBASE-15168.
---
Resolution: Won't Fix

Branch 1.1 is EOL

> Zombie stomping branch-1.1 edition
> --
>
> Key: HBASE-15168
> URL: https://issues.apache.org/jira/browse/HBASE-15168
> Project: HBase
>  Issue Type: Umbrella
>  Components: test
>Affects Versions: 1.1.0
>Reporter: Nick Dimiduk
>Priority: Critical
> Fix For: 1.1.7
>
>
> Let's bring back the work done on HBASE-14420 for branch-1.1, stabilize our 
> [builds|https://builds.apache.org/job/HBase-1.1-JDK7/]. Hang tickets here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-15308) Flakey TestSplitWalDataLoss on branch-1.1

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-15308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob resolved HBASE-15308.
---
Resolution: Won't Fix

Branch 1.1 is EOL

> Flakey TestSplitWalDataLoss on branch-1.1
> -
>
> Key: HBASE-15308
> URL: https://issues.apache.org/jira/browse/HBASE-15308
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Heng Chen
>Priority: Major
> Fix For: 1.1.7
>
>
> It happens during HBASE-15169 QA test,  see 
> https://builds.apache.org/job/PreCommit-HBASE-Build/628/artifact/patchprocess/patch-unit-hbase-server-jdk1.8.0_72.txt
> https://builds.apache.org/job/PreCommit-HBASE-Build/547/artifact/patchprocess/patch-unit-hbase-server-jdk1.8.0_72.txt



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-15185) Fix jdk8 javadoc warnings for branch-1.1

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-15185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob resolved HBASE-15185.
---
Resolution: Won't Fix

Branch 1.1 is EOL

> Fix jdk8 javadoc warnings for branch-1.1
> 
>
> Key: HBASE-15185
> URL: https://issues.apache.org/jira/browse/HBASE-15185
> Project: HBase
>  Issue Type: Task
>Affects Versions: 1.1.3
>Reporter: Yu Li
>Assignee: Zheng Hu
>Priority: Major
> Attachments: HBASE-15185.branch-1.1.patch, 
> HBASE-15185.branch-1.1.v2.patch, HBASE-15185.branch-1.1.v3.patch
>
>
> [This 
> link|https://builds.apache.org/job/PreCommit-HBASE-Build/340/artifact/patchprocess/patch-javadoc-hbase-server-jdk1.8.0_66.txt]
>  shows jdk8 javadoc warnings for current branch-1.1 code base.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] What should we bundle in our bin tarball?

[Stack]

Thanks lads. Let me look at purge of non-user javadocs and at building a
javadoc-only artifiact (then could purge all javadoc as per Andy).

S

On Tue, Mar 6, 2018 at 11:45 AM, Sean Busbey  wrote:

> if we keep any javadocs in the tarball they should just be the user
> facing javadocs (wether that includes testapidocs I could go either
> way). I'd be in favor of dumping the javadocs entirely from the binary
> tarball.
>
> do we know why the apidocs are bigger than our binaries? are we
> mistakingly include a source rendition in html again?
>
> We've been a bit spotty on keeping per-release-line javadocs up to
> date on the website. To give ourselves an out on that, what about
> including a release aritfact that's just a tarball of javadocs?
>
> On Tue, Mar 6, 2018 at 1:33 PM, Andrew Purtell 
> wrote:
> >> I could make it so we do not build dev doc by default or that we do not
> > include it in our bin tarball?
> >
> > The binary tarball is so huge at this point I think getting the size down
> > by pruning javadoc is reasonable, at least in the short term. We have
> > javadocs up on our site. They will also be available in Maven and your
> > favorite IDE should handle the automatic download and use of javadoc
> jars.
> >
> >
> > On Tue, Mar 6, 2018 at 11:29 AM, Stack  wrote:
> >
> >> On the vote thread for hbase-2.0.0-beta-2, it was noted that the bulk of
> >> our convenience bin tarball size is test javadoc [1] (~ > 50%). Should
> our
> >> bin tarball include all possible doc both api and dev api for both test
> and
> >> user?
> >>
> >> I could make it so we do not build dev doc by default or that we do not
> >> include it in our bin tarball? What do you all think?
> >>
> >> Thanks,
> >> St.Ack
> >>
> >>
> >> 1.
> >> $ cd hbase-2.0.0-beta-2
> >> $ du -sh *
> >> 256K CHANGES.txt
> >> 4.0K LEGAL
> >> 128K LICENSE.txt
> >> 420K NOTICE.txt
> >> 4.0K README.txt
> >> 184K bin
> >>  40K conf
> >> 818M docs
> >> 620K hbase-webapps
> >> 129M lib
> >>
> >> $ cd docs/
> >> $ du -sh *
> >>   0B _chapters
> >>  28K acid-semantics.html
> >>  11M apache_hbase_reference_guide.pdf
> >> 152M apidocs
> >>  32K asciidoctor.css
> >> 4.0K book
> >> 1.9M book.html
> >>  16K bulk-loads.html
> >>  20K coc.html
> >> 4.0K coderay-asciidoctor.css
> >> 116K css
> >>  36K cygwin.html
> >>  20K dependencies.html
> >> 272K dependency-convergence.html
> >>  16K dependency-info.html
> >>  48K dependency-management.html
> >> 332M devapidocs
> >> 4.0K doap_Hbase.rdf
> >>  16K export_control.html
> >> 200K fonts
> >>  32K hbase.css
> >> 2.5M images
> >>  28K img
> >>  20K index.html
> >>  16K integration.html
> >>  16K issue-tracking.html
> >> 148K js
> >>  28K license.html
> >>  16K mail-lists.html
> >>  20K metrics.html
> >>  24K old_news.html
> >>  20K plugin-management.html
> >>  20K plugins.html
> >>  40K poweredbyhbase.html
> >>  16K project-info.html
> >>  16K project-reports.html
> >>  16K project-summary.html
> >>  16K pseudo-distributed.html
> >>  16K replication.html
> >> 372K repo
> >>  16K resources.html
> >>  16K source-repository.html
> >>  16K sponsors.html
> >>  24K supportingprojects.html
> >>  32K team-list.html
> >> 112M testapidocs
> >> 205M testdevapidocs
> >>
> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
>

Re: [DISCUSS] strategy on Java versions

[Zach York]

> -- "Recommended" for running
>
> I think we should suggest folks rely on LTS releases of Java, wether
> from the OpenJDK project (which looks like it will be equivalent to
> the Oracle version) or a vender.
>
> That would mean updating our support matrix to call out Java 9 and
> Java 10 as "Not Supported" for current releases.
>

+1 for at least calling out Java 9 and Java 10 as "Not Tested" (Not
Supported if we know for sure it won't work).

As for recommending folks rely on LTS releases, I think this will require a
shift in thinking
from most people in the Hadoop ecosystem to upgrade the Java versions more
frequently.
Otherwise it will become a pain for users to use multiple open source
projects in the same
environment (for example if Hadoop is using Java 8, Spark - Java 9, and
HBase - Java 11).
Not saying that we should hold ourselves back because of other projects,
but we should
at least consider the burden.

I do, however, think that long term we should only recommend running with
the current LTS release.
Getting there might be a lot of fun though :)



>
> -- Development changes
>
> The next LTS version of Java is slated to be Java 11, which won't be
> out until September 2018. I think we should aim for a minor release on
> whatever major branches are still active within a month of the GA date
> where we feel comfortable calling out Java 11 as supported.
>
> To that end, I think we would should do 2 things:
>
> 1) Work to make sure we can run through our test suite with either the
> release prior to the next LTS or an early access version of the
> upcoming LTS release before the GA date, ideally ~3 months before.
> That'd be a target of June 2018 for the planned GA date of Java 11. I
> expect that means abandoning our Java 9 specific efforts and starting
> in April/May to work on updates related to Java 10 (or 11 depending on
> when bits start shipping).
>
>
+1, doesn't make sense doing work that will be already be obsolete by this
desired direction.


> 2) In the process of getting the above to work if we find we can't get
> a major release branch ready to go without violating our compatibility
> guidelines (especially wrt the existing supported java versions), we
> should cease making new minor releases for that major release branch.
> This could mean either just going to bugfix releases or it could mean
> declaring the branch EOM entirely.
>
> Note that the above doesn't necessarily require that we be able to
> build with a newer JDK version. That would certainly be simpler
> though; I don't think our current tooling makes it easy to run tests
> with a different JDK than is used to compile.
>
> -- Dropping of older versions
>
> I don't think we've codified anywhere when we drop Java version
> supports? (our guide merely says when we _could_.) I'm also not sure
> if we should write it down somewhere? If we can stick to the above and
> proactively add new versions as supported in minor releases, I think
> we'll be in a good position to drop everything but the latest LTS Java
> release with each HBase major release. Since this notion of LTS and
> non-LTS releases for Java is still relatively new, maybe that's a
> discussion we're better off having once HBase 3 is closer.
>

I don't see this happening before 3.0 anyways. Let's work on getting 1)
done for Java 9/10.
I think we should wait until we see how this is all going to pan out (and
how much work each upgrade will be)
before making anything public, but I think this is a good goal.

Thanks for writing this up,
Zach

Re: [DISCUSS] What should we bundle in our bin tarball?

[Sean Busbey]

if we keep any javadocs in the tarball they should just be the user
facing javadocs (wether that includes testapidocs I could go either
way). I'd be in favor of dumping the javadocs entirely from the binary
tarball.

do we know why the apidocs are bigger than our binaries? are we
mistakingly include a source rendition in html again?

We've been a bit spotty on keeping per-release-line javadocs up to
date on the website. To give ourselves an out on that, what about
including a release aritfact that's just a tarball of javadocs?

On Tue, Mar 6, 2018 at 1:33 PM, Andrew Purtell  wrote:
>> I could make it so we do not build dev doc by default or that we do not
> include it in our bin tarball?
>
> The binary tarball is so huge at this point I think getting the size down
> by pruning javadoc is reasonable, at least in the short term. We have
> javadocs up on our site. They will also be available in Maven and your
> favorite IDE should handle the automatic download and use of javadoc jars.
>
>
> On Tue, Mar 6, 2018 at 11:29 AM, Stack  wrote:
>
>> On the vote thread for hbase-2.0.0-beta-2, it was noted that the bulk of
>> our convenience bin tarball size is test javadoc [1] (~ > 50%). Should our
>> bin tarball include all possible doc both api and dev api for both test and
>> user?
>>
>> I could make it so we do not build dev doc by default or that we do not
>> include it in our bin tarball? What do you all think?
>>
>> Thanks,
>> St.Ack
>>
>>
>> 1.
>> $ cd hbase-2.0.0-beta-2
>> $ du -sh *
>> 256K CHANGES.txt
>> 4.0K LEGAL
>> 128K LICENSE.txt
>> 420K NOTICE.txt
>> 4.0K README.txt
>> 184K bin
>>  40K conf
>> 818M docs
>> 620K hbase-webapps
>> 129M lib
>>
>> $ cd docs/
>> $ du -sh *
>>   0B _chapters
>>  28K acid-semantics.html
>>  11M apache_hbase_reference_guide.pdf
>> 152M apidocs
>>  32K asciidoctor.css
>> 4.0K book
>> 1.9M book.html
>>  16K bulk-loads.html
>>  20K coc.html
>> 4.0K coderay-asciidoctor.css
>> 116K css
>>  36K cygwin.html
>>  20K dependencies.html
>> 272K dependency-convergence.html
>>  16K dependency-info.html
>>  48K dependency-management.html
>> 332M devapidocs
>> 4.0K doap_Hbase.rdf
>>  16K export_control.html
>> 200K fonts
>>  32K hbase.css
>> 2.5M images
>>  28K img
>>  20K index.html
>>  16K integration.html
>>  16K issue-tracking.html
>> 148K js
>>  28K license.html
>>  16K mail-lists.html
>>  20K metrics.html
>>  24K old_news.html
>>  20K plugin-management.html
>>  20K plugins.html
>>  40K poweredbyhbase.html
>>  16K project-info.html
>>  16K project-reports.html
>>  16K project-summary.html
>>  16K pseudo-distributed.html
>>  16K replication.html
>> 372K repo
>>  16K resources.html
>>  16K source-repository.html
>>  16K sponsors.html
>>  24K supportingprojects.html
>>  32K team-list.html
>> 112M testapidocs
>> 205M testdevapidocs
>>
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk

[jira] [Resolved] (HBASE-14341) branch-1.1 source assembly contains spurious hbase-shaded-client and hbase-shaded-server modules

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-14341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob resolved HBASE-14341.
---
Resolution: Won't Fix

branch-1.1 is EOL

> branch-1.1 source assembly contains spurious hbase-shaded-client and 
> hbase-shaded-server modules
> 
>
> Key: HBASE-14341
> URL: https://issues.apache.org/jira/browse/HBASE-14341
> Project: HBase
>  Issue Type: Bug
>  Components: build
>Affects Versions: 1.1.2
>Reporter: Sean Busbey
>Priority: Major
>
> if you build a source assembly according to the book:
> {quote}
> mvn clean install -DskipTests assembly:single 
> -Dassembly.file=hbase-assembly/src/main/assembly/src.xml -Prelease
> {quote}
> Then the resultant artifact has an extra set of the shaded modules at the top 
> level (in addition to the ones in the hbase-shaded module)
> {code}
> $ ls -lah hbase-1.1.2/
> total 608
> drwxr-xr-x  32 busbey  staff   1.1K Aug 30 17:14 .
> drwxr-xr-x   3 busbey  staff   102B Aug 30 17:14 ..
> -rw-r--r--   1 busbey  staff   162K Aug 30 16:42 CHANGES.txt
> -rw-r--r--   1 busbey  staff36K Aug 30 16:15 LICENSE.txt
> -rw-r--r--   1 busbey  staff   1.5K Aug 30 16:15 NOTICE.txt
> -rw-r--r--   1 busbey  staff   1.4K Aug 30 16:15 README.txt
> drwxr-xr-x  31 busbey  staff   1.0K Aug 30 16:42 bin
> drwxr-xr-x   9 busbey  staff   306B Aug 30 16:42 conf
> drwxr-xr-x  24 busbey  staff   816B Aug 30 16:42 dev-support
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:56 hbase-annotations
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:58 hbase-assembly
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:56 hbase-checkstyle
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:57 hbase-client
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:56 hbase-common
> drwxr-xr-x   5 busbey  staff   170B Aug 30 16:58 hbase-examples
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:57 hbase-hadoop-compat
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:57 hbase-hadoop2-compat
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:58 hbase-it
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:57 hbase-prefix-tree
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:56 hbase-procedure
> drwxr-xr-x   5 busbey  staff   170B Aug 30 16:56 hbase-protocol
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:56 hbase-resource-bundle
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:57 hbase-rest
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:57 hbase-server
> drwxr-xr-x   5 busbey  staff   170B Aug 30 16:42 hbase-shaded
> drwxr-xr-x   3 busbey  staff   102B Aug 30 16:42 hbase-shaded-client
> drwxr-xr-x   3 busbey  staff   102B Aug 30 16:42 hbase-shaded-server
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:58 hbase-shell
> drwxr-xr-x   3 busbey  staff   102B Aug 30 16:57 hbase-testing-util
> drwxr-xr-x   4 busbey  staff   136B Aug 30 16:57 hbase-thrift
> -rw-r--r--   1 busbey  staff94K Aug 30 16:42 pom.xml
> drwxr-xr-x   3 busbey  staff   102B Aug 30 16:15 src
> $ diff -r hbase-1.1.2/hbase-shaded-client 
> hbase-1.1.2/hbase-shaded/hbase-shaded-client
> Only in hbase-1.1.2/hbase-shaded/hbase-shaded-client: target
> $ diff -r hbase-1.1.2/hbase-shaded-server 
> hbase-1.1.2/hbase-shaded/hbase-shaded-server
> Only in hbase-1.1.2/hbase-shaded/hbase-shaded-server: target
> {code}
> they're the same as the correct ones and they don't build by default since 
> the top level pom doesn't mention them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20142) Copy master doc into branch-2 and edit to make it suit 2.0.0

[stack (JIRA)]

stack created HBASE-20142:
-

 Summary: Copy master doc into branch-2 and edit to make it suit 
2.0.0
 Key: HBASE-20142
 URL: https://issues.apache.org/jira/browse/HBASE-20142
 Project: HBase
  Issue Type: Sub-task
Reporter: stack


Place-holder for task to be done before we RC... copy the master refguide into 
branch-2 and do a pass to make sure it hbase-2 appropriate.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] What should we bundle in our bin tarball?

[Andrew Purtell]

> I could make it so we do not build dev doc by default or that we do not
include it in our bin tarball?

The binary tarball is so huge at this point I think getting the size down
by pruning javadoc is reasonable, at least in the short term. We have
javadocs up on our site. They will also be available in Maven and your
favorite IDE should handle the automatic download and use of javadoc jars.


On Tue, Mar 6, 2018 at 11:29 AM, Stack  wrote:

> On the vote thread for hbase-2.0.0-beta-2, it was noted that the bulk of
> our convenience bin tarball size is test javadoc [1] (~ > 50%). Should our
> bin tarball include all possible doc both api and dev api for both test and
> user?
>
> I could make it so we do not build dev doc by default or that we do not
> include it in our bin tarball? What do you all think?
>
> Thanks,
> St.Ack
>
>
> 1.
> $ cd hbase-2.0.0-beta-2
> $ du -sh *
> 256K CHANGES.txt
> 4.0K LEGAL
> 128K LICENSE.txt
> 420K NOTICE.txt
> 4.0K README.txt
> 184K bin
>  40K conf
> 818M docs
> 620K hbase-webapps
> 129M lib
>
> $ cd docs/
> $ du -sh *
>   0B _chapters
>  28K acid-semantics.html
>  11M apache_hbase_reference_guide.pdf
> 152M apidocs
>  32K asciidoctor.css
> 4.0K book
> 1.9M book.html
>  16K bulk-loads.html
>  20K coc.html
> 4.0K coderay-asciidoctor.css
> 116K css
>  36K cygwin.html
>  20K dependencies.html
> 272K dependency-convergence.html
>  16K dependency-info.html
>  48K dependency-management.html
> 332M devapidocs
> 4.0K doap_Hbase.rdf
>  16K export_control.html
> 200K fonts
>  32K hbase.css
> 2.5M images
>  28K img
>  20K index.html
>  16K integration.html
>  16K issue-tracking.html
> 148K js
>  28K license.html
>  16K mail-lists.html
>  20K metrics.html
>  24K old_news.html
>  20K plugin-management.html
>  20K plugins.html
>  40K poweredbyhbase.html
>  16K project-info.html
>  16K project-reports.html
>  16K project-summary.html
>  16K pseudo-distributed.html
>  16K replication.html
> 372K repo
>  16K resources.html
>  16K source-repository.html
>  16K sponsors.html
>  24K supportingprojects.html
>  32K team-list.html
> 112M testapidocs
> 205M testdevapidocs
>



-- 
Best regards,
Andrew

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

[jira] [Created] (HBASE-20141) Fix TooManyFiles exception when RefreshingChannels in FileIOEngine

[Zach York (JIRA)]

Zach York created HBASE-20141:
-

 Summary: Fix TooManyFiles exception when RefreshingChannels in 
FileIOEngine
 Key: HBASE-20141
 URL: https://issues.apache.org/jira/browse/HBASE-20141
 Project: HBase
  Issue Type: Bug
  Components: BucketCache
Affects Versions: 1.4.2, 2.0.0-beta-1, 1.4.0
Reporter: Zach York
Assignee: Zach York


HBASE-19435 implements a fix for reopening file channels when they are 
unnexpected closed
to avoid disabling the BucketCache. However, it was missed that the the 
channels might not
actually be completely closed (the write or read channel might still be open
(see 
https://docs.oracle.com/javase/7/docs/api/java/nio/channels/ClosedChannelException.html)
This commit closes any open channels before creating a new channel.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[DISCUSS] What should we bundle in our bin tarball?

[Stack]

On the vote thread for hbase-2.0.0-beta-2, it was noted that the bulk of
our convenience bin tarball size is test javadoc [1] (~ > 50%). Should our
bin tarball include all possible doc both api and dev api for both test and
user?

I could make it so we do not build dev doc by default or that we do not
include it in our bin tarball? What do you all think?

Thanks,
St.Ack


1.
$ cd hbase-2.0.0-beta-2
$ du -sh *
256K CHANGES.txt
4.0K LEGAL
128K LICENSE.txt
420K NOTICE.txt
4.0K README.txt
184K bin
 40K conf
818M docs
620K hbase-webapps
129M lib

$ cd docs/
$ du -sh *
  0B _chapters
 28K acid-semantics.html
 11M apache_hbase_reference_guide.pdf
152M apidocs
 32K asciidoctor.css
4.0K book
1.9M book.html
 16K bulk-loads.html
 20K coc.html
4.0K coderay-asciidoctor.css
116K css
 36K cygwin.html
 20K dependencies.html
272K dependency-convergence.html
 16K dependency-info.html
 48K dependency-management.html
332M devapidocs
4.0K doap_Hbase.rdf
 16K export_control.html
200K fonts
 32K hbase.css
2.5M images
 28K img
 20K index.html
 16K integration.html
 16K issue-tracking.html
148K js
 28K license.html
 16K mail-lists.html
 20K metrics.html
 24K old_news.html
 20K plugin-management.html
 20K plugins.html
 40K poweredbyhbase.html
 16K project-info.html
 16K project-reports.html
 16K project-summary.html
 16K pseudo-distributed.html
 16K replication.html
372K repo
 16K resources.html
 16K source-repository.html
 16K sponsors.html
 24K supportingprojects.html
 32K team-list.html
112M testapidocs
205M testdevapidocs

Re: [VOTE] The first hbase-2.0.0-beta-2 Release Candidate is available for download

[Artem Ervits]

+1 (non-binding)

Hadoop Pseudo-distrbibuted: 2.7.5
$M2_HOME from scratch
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T07:58:13Z)
Maven home: /opt/maven/apache-maven-3.5.2
Java version: 1.8.0_161, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.10.0-693.11.6.el7.x86_64", arch: "amd64",
family: "unix"

Binary Release:
Java 1M rows: OK
LTT 1M rows: OK
PE 1M rows: OK
MD5: OK

hbase shell: OK
create, list, scan, count, truncate, disable, drop
snapshot, restore_snapshot
UI:
  split: OK
  merge: OK

Source Release:
Build with: mvn clean -DskipTests -Dhadoop-two.version=2.7.5
install && mvn clean -DskipTests -Dhadoop-two.version=2.7.5 package
assembly:single   OK
MD5: OK
installed and ran from src: OK

mvn test -P runSmallTests: NOK (this can be my own environment and I've
surfaced this in votes for 1.4.1 and 1.4.2 but failing class is the same
but failure is different.

  [ESC[1;34mINFOESC[m] Results:
[ESC[1;34mINFOESC[m]
[ESC[1;31mERRORESC[m] ESC[1;31mFailures: ESC[m
[ESC[1;31mERRORESC[m] ESC[1;31m
TestSpnegoHttpServer.testAllowedClient:243->Assert.assertEquals:631->Assert.assertEquals:645->Assert.failNotEquals:834->Assert.fail:88
expected:<200> but was:<401>ESC[m
[ESC[1;34mINFOESC[m]

On Tue, Mar 6, 2018 at 10:57 AM, Josh Elser  wrote:

> +1 (binding)
>
> * src release OK
> * xsums/sigs OK
> * Can build and run from src OK
> * Loaded some data locally
>
>
> On 3/2/18 6:40 PM, Stack wrote:
>
>> The first release candidate for HBase 2.0.0-beta-2 is up at
>>
>>   https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0-beta-2.RC0/
>>
>> Maven artifacts are available from a staging directory here:
>>
>>https://repository.apache.org/content/repositories/orgapachehbase-1199
>>
>> All was signed with my key at 8ACC93D2 [1]
>>
>> I tagged the RC as 2.0.0-beta-2RC0.2 at
>> 9e9b347d667e1fc6165c9f8ae5ae7052147e8895
>>
>> hbase-2.0.0-beta-2 is a not-for-production preview of hbase-2.0.0. It is
>> meant for devs and downstreamers to test drive and flag us if we messed up
>> on anything ahead of our rolling
>> actual 2.0.0 release candidates ("GAs").
>>
>> hbase-2.0.0-beta-2 is our second beta release. More than 200 fixes have
>> gone in since
>> beta-1. Unit tests generallly pass when run against hadoop2 and
>> hadoop3[5].
>> It includes
>> all that was in previous alphas and beta (new assignment manager, offheap
>> read/write
>> path, in-memory compactions, etc).The list of features addressed in 2.0.0
>> so far can be
>> found here [3]. There are thousands. The list of ~3k+ fixes in 2.0.0
>> exclusively can be
>> found here [4]. Our overview doc. on the state of 2.0.0 is at [6].
>>
>> This beta was supposed to have as its focus rolling upgrade from hbase-1.x
>> versions but
>> this is work not complete (At this late stage, it is looking like it will
>> be a post-2.0.0 project).
>>
>> This is our last hbase-2.0.0 beta release. Next up, we'll be rolling an
>> actual 2.0.0 release
>> candidate. Look for this in a week or two after beta-2 goes out, after
>> we've done more
>> testing and documentation (and we fix issues raised by you all against
>> this
>> beta).
>>
>> One known issue, still unaddressed, is that the User API has not been
>> properly filtered
>> so it shows more than just InterfaceAudience Public content (HBASE-19663,
>> to be fixed
>> by release).
>>
>> Please take this beta for a spin. Please vote on whether it ok to put out
>> this RC as our second
>> beta (Note CHANGES has not yet been updated). Let the VOTE be open for at
>> least 72 hours
>> (Lets say Wednesday morning, March 7th).
>>
>> Thanks,
>> Your 2.0.0 Release Manager
>>
>> 1. http://pgp.mit.edu/pks/lookup?op=get=0x9816C7FC8ACC93D2
>> 3. https://goo.gl/scYjJr
>> 4. https://goo.gl/dFFT8b
>> 5. https://builds.apache.org/job/HBase%20Nightly/job/branch-2/
>> 
>> 6. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4
>> z9iEu_ktczrlKHK8N4SZzs/
>>
>>

Re: Please hold on commits to branch-2; cutting an hbase-2.0.0-beta-2 Release Candidate

[Sean Busbey]

Is branch-2 open again now? Sorry if I missed the all-clear but I
could not find it.

On Thu, Mar 1, 2018 at 11:59 AM, Stack  wrote:
> Short Version: Please hold on making commits to branch-2. I am in the
> process of cutting a hbase-2.0.0-beta-2 release candidate. It make take me
> a day or so.
>
> Long Version:
>
> A miracle happened last night. Our nightly for branch-2 passed [1]. This
> means all unit tests ran against hadoop2 and then subsequently, all unit
> tests ran against hadoop3. It had been threatening for a while. A few
> recent builds passed all unit tests only to fail on a few findbugs issues.
>
> Given this momentous event and that there are over 200 fixes since beta-1,
> it is time to push out a beta-2.
>
> Originally beta-2 was supposed to be about making sure we could do a
> rolling upgrade from branch-1 to branch-2. This was its theme. The work has
> not been done. Also, a bunch of work is still to be done around testing,
> compatibility checking, and performance. Perhaps folks are waiting on the
> 2.0.0 release candidate before they dig in (smile)?
>
> I'll give the all clear once I've cut my release. Thank you for your
> patience.
> St.Ack
>
>
> 1. See build #415 here
> https://builds.apache.org/job/HBase%20Nightly/job/branch-2/

[DISCUSS] strategy on Java versions

[Sean Busbey]

Hi folks!

Our ref guide section on Java versions[1] is starting to look dated,
because the Oracle version of Java 9 hits end of public updates this
month and we don't mention it at all.

I'd like to discuss how we want to approach keeping HBase up-to-date
on new Java versions.

As background, the Java community is moving to a time-based release
schedule where there is a new long term support (LTS) version every
~three years[2]. Between those, there are a series of feature releases
that only have a short window of receiving updates.

-- "Recommended" for running

I think we should suggest folks rely on LTS releases of Java, wether
from the OpenJDK project (which looks like it will be equivalent to
the Oracle version) or a vender.

That would mean updating our support matrix to call out Java 9 and
Java 10 as "Not Supported" for current releases.

-- Development changes

The next LTS version of Java is slated to be Java 11, which won't be
out until September 2018. I think we should aim for a minor release on
whatever major branches are still active within a month of the GA date
where we feel comfortable calling out Java 11 as supported.

To that end, I think we would should do 2 things:

1) Work to make sure we can run through our test suite with either the
release prior to the next LTS or an early access version of the
upcoming LTS release before the GA date, ideally ~3 months before.
That'd be a target of June 2018 for the planned GA date of Java 11. I
expect that means abandoning our Java 9 specific efforts and starting
in April/May to work on updates related to Java 10 (or 11 depending on
when bits start shipping).

2) In the process of getting the above to work if we find we can't get
a major release branch ready to go without violating our compatibility
guidelines (especially wrt the existing supported java versions), we
should cease making new minor releases for that major release branch.
This could mean either just going to bugfix releases or it could mean
declaring the branch EOM entirely.

Note that the above doesn't necessarily require that we be able to
build with a newer JDK version. That would certainly be simpler
though; I don't think our current tooling makes it easy to run tests
with a different JDK than is used to compile.

-- Dropping of older versions

I don't think we've codified anywhere when we drop Java version
supports? (our guide merely says when we _could_.) I'm also not sure
if we should write it down somewhere? If we can stick to the above and
proactively add new versions as supported in minor releases, I think
we'll be in a good position to drop everything but the latest LTS Java
release with each HBase major release. Since this notion of LTS and
non-LTS releases for Java is still relatively new, maybe that's a
discussion we're better off having once HBase 3 is closer.

[1]: http://hbase.apache.org/book.html#java
[2]: http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html

Re: [VOTE] The first hbase-2.0.0-beta-2 Release Candidate is available for download

[Josh Elser]

+1 (binding)

* src release OK
* xsums/sigs OK
* Can build and run from src OK
* Loaded some data locally

On 3/2/18 6:40 PM, Stack wrote:

The first release candidate for HBase 2.0.0-beta-2 is up at

  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0-beta-2.RC0/

Maven artifacts are available from a staging directory here:

   https://repository.apache.org/content/repositories/orgapachehbase-1199

All was signed with my key at 8ACC93D2 [1]

I tagged the RC as 2.0.0-beta-2RC0.2 at
9e9b347d667e1fc6165c9f8ae5ae7052147e8895

hbase-2.0.0-beta-2 is a not-for-production preview of hbase-2.0.0. It is
meant for devs and downstreamers to test drive and flag us if we messed up
on anything ahead of our rolling
actual 2.0.0 release candidates ("GAs").

hbase-2.0.0-beta-2 is our second beta release. More than 200 fixes have
gone in since
beta-1. Unit tests generallly pass when run against hadoop2 and hadoop3[5].
It includes
all that was in previous alphas and beta (new assignment manager, offheap
read/write
path, in-memory compactions, etc).The list of features addressed in 2.0.0
so far can be
found here [3]. There are thousands. The list of ~3k+ fixes in 2.0.0
exclusively can be
found here [4]. Our overview doc. on the state of 2.0.0 is at [6].

This beta was supposed to have as its focus rolling upgrade from hbase-1.x
versions but
this is work not complete (At this late stage, it is looking like it will
be a post-2.0.0 project).

This is our last hbase-2.0.0 beta release. Next up, we'll be rolling an
actual 2.0.0 release
candidate. Look for this in a week or two after beta-2 goes out, after
we've done more
testing and documentation (and we fix issues raised by you all against this
beta).

One known issue, still unaddressed, is that the User API has not been
properly filtered
so it shows more than just InterfaceAudience Public content (HBASE-19663,
to be fixed
by release).

Please take this beta for a spin. Please vote on whether it ok to put out
this RC as our second
beta (Note CHANGES has not yet been updated). Let the VOTE be open for at
least 72 hours
(Lets say Wednesday morning, March 7th).

Thanks,
Your 2.0.0 Release Manager

1. http://pgp.mit.edu/pks/lookup?op=get=0x9816C7FC8ACC93D2
3. https://goo.gl/scYjJr
4. https://goo.gl/dFFT8b
5. https://builds.apache.org/job/HBase%20Nightly/job/branch-2/

6. https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4
z9iEu_ktczrlKHK8N4SZzs/

docs review request HBASE-20072

[Sean Busbey]

Could a committer take a few minutes to review the changes here:

https://issues.apache.org/jira/browse/HBASE-20072

1.1 has been EOM for coming up on 3 months and this jira updates our
docs to better reflect that.

Re: [VOTE] The first hbase-2.0.0-beta-2 Release Candidate is available for download

[Josh Elser]

On 3/5/18 2:40 PM, Stack wrote:

On Mon, Mar 5, 2018 at 6:56 AM, Chia-Ping Tsai  wrote:


+1 (binding) with some questions
unit test (oracle jdk-8u161) - all pass
deploy binary (3 nodes) - ok
browse master/regionserver web - LGTM
put/delete/get/scan 500W rows - ok
create/disable/drop/put/scan/count by shell - ok

Q1:
the 2.0 binary get fatter than 1.4. (384 MB -> 887MB). Seems we package
the test docs and source code to binary tar. Are all of them necessary?



No. Let me review.


Holy moly. We ship 7x more javadocs than JAR files (in terms of size on 
disk).


IMO, remove all but apidocs with gusto. Looking at what's contained in 
apidocs, I think we should also reduce that much farther (e.g. 
RegionServer javadoc is included?), but maybe that's another discussion.

[jira] [Created] (HBASE-20140) HRegion FileSystem should be instantiated from hbase rootDir not default

[Adrian Muraru (JIRA)]

Adrian Muraru created HBASE-20140:
-

 Summary: HRegion FileSystem should be instantiated from hbase 
rootDir not default
 Key: HBASE-20140
 URL: https://issues.apache.org/jira/browse/HBASE-20140
 Project: HBase
  Issue Type: Improvement
  Components: regionserver
Reporter: Adrian Muraru


HRegion fs initialization is done based on HDFS default {{fs.defaultFs}} 
instead of {{hbase.rootdir}}

This is breaking in cases where the {{fs.defaultFs}} is set to a different  
filesystem than the one set in fully qualified {{hbase.rootdir}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-20126) Add UT for serial replication after region merge

[Duo Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-20126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-20126.
---
Resolution: Duplicate

> Add UT for serial replication after region merge
> 
>
> Key: HBASE-20126
> URL: https://issues.apache.org/jira/browse/HBASE-20126
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Duo Zhang
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20139) NPE in RSRpcServices.get() when getRegion throws an exception

[Abhishek Singh Chouhan (JIRA)]

Abhishek Singh Chouhan created HBASE-20139:
--

 Summary: NPE in RSRpcServices.get() when getRegion throws an 
exception
 Key: HBASE-20139
 URL: https://issues.apache.org/jira/browse/HBASE-20139
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.3.1
Reporter: Abhishek Singh Chouhan
Assignee: Abhishek Singh Chouhan
 Fix For: 1.3.2, 1.5.0, 1.4.3


We can get a NPE in RsRpcServices at 
{code:java}
} finally {
if (regionServer.metricsRegionServer != null) {
regionServer.metricsRegionServer.updateGet(
-> region.getTableDesc().getTableName(), EnvironmentEdgeManager.currentTime() - 
before);
}
if (quota != null) {
quota.close();
}{code}
when region itself is null which might happen when getRegion throws an 
exception, this is then sent back to the client which is not able to handle 
this/make sense of it.
{code:java}
2018-03-06 08:31:25,100 DEBUG [0,queue=4,port=60020] ipc.RpcServer - 
RpcServer.FifoWFPBQ.default.handler=30,queue=4,port=60020: callId: 5605567 
service: ClientService methodName: Get size: 79 connection: xyz:58736 deadline: 
9223372036854775807
java.io.IOException
        at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2431)
        at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:124)
        at 
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:188)
        at 
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:168)
Caused by: java.lang.NullPointerException
        at 
org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2246)
        at 
org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:35068)
        at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2373)
        ... 3 more{code}
This has been fixed by [~stack] over at HBASE-18946 for master, backporting the 
same to branch-1, 1.3 and 1.4



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20138) Find a way to deal with the conflicts when updating replication position

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-20138:
-

 Summary: Find a way to deal with the conflicts when updating 
replication position
 Key: HBASE-20138
 URL: https://issues.apache.org/jira/browse/HBASE-20138
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang


For now if a table is not created with SERIAL_REPLICATION_SCOPE and later 
converted to SERIAL_REPLICATION_SCOPE , then we may have multiple replication 
sources which replicate the different ranges for the same region and update the 
queue storage concurrently. This will cause problem if the lower range finish 
at last since the replication position will be wrong...

Need to find a way to deal with this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)