Re: Failure: HBase Generate Website

[Peter Somogyi]

I've created HBASE-18320 
.
The new maven-site-plugin and asciidoctor plugin versions are not
compatible with the currently used site.xml. I've started to work on it. I
think the quickest would be to roll back these plugins to the previous
versions and after we can investigate if we need the new versions or not.

Peter

On Tue, Jul 4, 2017 at 4:40 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> Build status: Failure
>
> The HBase website has not been updated to incorporate HBase commit
> ${HBASE_GIT_SHA}.
>
> See https://builds.apache.org/job/hbase_generate_website/1043/console

Different behavior in ScannerCallables

[Peter Somogyi]

Hi,

I noticed that the behavior of ReversedScannerCallable#prepare [1]
and ScannerCallable#prepare [2] methods differ how they
call RpcRetryingCallerWithReadReplicas.getRegionLocations method.

The reversed scanner uses the 'reload' parameter directly as the first
argument - RpcRetryingCallerWithReadReplicas.getRegionLocations(reload, id,
getConnection(), getTableName(), getRow()) - however, the forward scanner
passes '!reload'. The getRegionLocations first parameter is 'useCache', so
I think the way we use it in ScannerCallable is the correct one.

The same call can be found in ReversedScannerCallable#locateRegionsInRange
[3] also without negating its value.

Is it supposed to work like this? If not I can create a Jira and fix the
issue.

Thanks,
Peter

[1]
https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/ReversedScannerCallable.java#L89-L90
[2]
https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/ScannerCallable.java#L139-L140
[3]
https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/ReversedScannerCallable.java#L143-L144

Re: Problem with IntegrationTestRegionReplicaReplication

[Peter Somogyi]

I made some testing and found an interesting behavior that you might be
able to comment on.

When running the test against apache/branch-1.1 and apache/branch-1.2 using
the following command the tests consistently failed for me:
`mvn -pl hbase-it -am -Dtest=NoUnitTests
-Dit.test=IntegrationTestRegionReplicaReplication verify`

If I remove line 103 from the test then the test passes on both apache
branch and CDH based on v.1.2.
conf.setLong(HConstants.HREGION_MEMSTORE_FLUSH_SIZE, 1024L * 1024 * 4);
// flush every 4 MB

Do you know why setting hbase.hregion.memstore.flush.size is needed? As far
as I understand the test verifies that async WAL replication works. Don't
we bypass that functionality if we flush too frequently?

Thanks,
Peter

On Mon, Jun 19, 2017 at 2:55 AM, Devaraj Das <d...@hortonworks.com> wrote:

> If it is failing consistently I'd suspect we have introduced a bug in the
> 1.2 line or something. We do run the same test with a version based on
> 1.1.2 (HDP-2.3 and beyond) and it works fine
>
>
>
>
> On Sun, Jun 18, 2017 at 8:26 AM -0700, "Peter Somogyi" <
> psomo...@cloudera.com<mailto:psomo...@cloudera.com>> wrote:
>
>
> I'm using hbase based on 1.2 version.
>
> On Sat, Jun 17, 2017 at 4:00 PM, Devaraj Das  wrote:
>
> > Peter which version of HBase are tou testing with?
> >
> >
> >
> >
> > On Thu, Jun 15, 2017 at 11:57 PM -0700, "Peter Somogyi" <
> > psomo...@cloudera.com> wrote:
> >
> >
> > I tried with those parameters but the test still failed.
> > I noticed that some of the rows were not replicated to the replicas just
> > after I called flush manually. I think memstore replication is not
> working
> > on my system even though it is enabled in the configuration.
> > I will look into it today.
> >
> > On Fri, Jun 16, 2017 at 7:09 AM, Devaraj Das  wrote:
> >
> > > Peter, do have a look at IntegrationTestRegionReplicaReplication.java
> ..
> > > At the top of the file, the ways to specify the options are documented
> ..
> > > You need to add something like -DIntegrationTestRegionReplicaR
> > eplication.read_delay_ms
> > > ..
> > > 
> > > From: Josh Elser
> > > Sent: Thursday, June 15, 2017 10:40 AM
> > > To: dev@hbase.apache.org
> > > Subject: Re: Problem with IntegrationTestRegionReplicaReplication
> > >
> > > I'd start trying a read_delay_ms=60000, region_replication=2,
> > > num_keys_per_server=5000, num_regions_per_server=5 with a maybe 10's of
> > > reader and writer threads.
> > >
> > > Again, this can be quite dependent on the kind of hardware you have.
> > > You'll definitely have to tweak ;)
> > >
> > > On 6/15/17 4:44 AM, Peter Somogyi wrote:
> > > > Thanks Josh and Devaraj!
> > > >
> > > > I will try to increase the timeouts. Devaraj, could you share the
> > > > parameters you used for this test which worked?
> > > >
> > > > On Thu, Jun 15, 2017 at 6:44 AM, Devaraj Das
> > > wrote:
> > > >
> > > >> That sounds about right, Josh. Peter, in our internal testing we
> have
> > > seen
> > > >> this test failing and increasing timeouts (look at the test code
> > > options to
> > > >> do with increasing timeout) helped quite some.
> > > >> 
> > > >> From: Josh Elser
> > > >> Sent: Wednesday, June 14, 2017 3:17 PM
> > > >> To: dev@hbase.apache.org
> > > >> Subject: Re: Problem with IntegrationTestRegionReplicaReplication
> > > >>
> > > >> On 6/14/17 3:53 AM, Peter Somogyi wrote:
> > > >>> Hi,
> > > >>>
> > > >>> As one of my first task with HBase I started to look into
> > > >>> why IntegrationTestRegionReplicaReplication fails. I would like to
> > get
> > > >> some
> > > >>> suggestions from you.
> > > >>>
> > > >>> I noticed when I run the test using normal cluster or minicluster I
> > get
> > > >> the
> > > >>> same error messages: "Error checking data for key [null], no data
> > > >>> returned". I looked into the code and here are my conclusions.
> > > >>>
> > > >>> There are multiple threads writing data parallel which are read by
> > > >> multiple
> > > >>> reader threads simultaneously. Each writer

Re: Problem with IntegrationTestRegionReplicaReplication

[Peter Somogyi]

Thanks Josh and Devaraj!

I will try to increase the timeouts. Devaraj, could you share the
parameters you used for this test which worked?

On Thu, Jun 15, 2017 at 6:44 AM, Devaraj Das <d...@hortonworks.com> wrote:

> That sounds about right, Josh. Peter, in our internal testing we have seen
> this test failing and increasing timeouts (look at the test code options to
> do with increasing timeout) helped quite some.
> 
> From: Josh Elser <josh.el...@gmail.com>
> Sent: Wednesday, June 14, 2017 3:17 PM
> To: dev@hbase.apache.org
> Subject: Re: Problem with IntegrationTestRegionReplicaReplication
>
> On 6/14/17 3:53 AM, Peter Somogyi wrote:
> > Hi,
> >
> > As one of my first task with HBase I started to look into
> > why IntegrationTestRegionReplicaReplication fails. I would like to get
> some
> > suggestions from you.
> >
> > I noticed when I run the test using normal cluster or minicluster I get
> the
> > same error messages: "Error checking data for key [null], no data
> > returned". I looked into the code and here are my conclusions.
> >
> > There are multiple threads writing data parallel which are read by
> multiple
> > reader threads simultaneously. Each writer gets a portion of the keys to
> > write (e.g. 0-2000) and these keys are added to a ConstantDelayQueue.
> > The reader threads get the elements (e.g. key=1000) from the queue and
> > these reader threads assume that all the keys up to this are already in
> the
> > database. Since we're using multiple writers it can happen that another
> > thread has not yet written key=500 and verifying these keys will cause
> the
> > test failure.
> >
> > Do you think my assumption is correct?
>
> Hi Peter,
>
> No, as my memory serves, this is not correct. Readers are not made aware
> of keys to verify until the write occur plus some delay. The delay is
> used to provide enough time for the internal region replication to take
> effect.
>
> So: primary-write, pause, [region replication happens in background],
> add updated key to read queue, reader gets key from queue verifies the
> value on a replica.
>
> The primary should always have seen the new value for a key. If the test
> is showing that a replica does not see the result, it's either a timing
> issue (you need to give a larger delay for HBase to perform the region
> replication) or a bug in the region replication framework itself. That
> said, if you can show that you are seeing what you describe, that sounds
> like the test framework itself is broken :)
>
>
>
>

Problem with IntegrationTestRegionReplicaReplication

[Peter Somogyi]

Hi,

As one of my first task with HBase I started to look into
why IntegrationTestRegionReplicaReplication fails. I would like to get some
suggestions from you.

I noticed when I run the test using normal cluster or minicluster I get the
same error messages: "Error checking data for key [null], no data
returned". I looked into the code and here are my conclusions.

There are multiple threads writing data parallel which are read by multiple
reader threads simultaneously. Each writer gets a portion of the keys to
write (e.g. 0-2000) and these keys are added to a ConstantDelayQueue.
The reader threads get the elements (e.g. key=1000) from the queue and
these reader threads assume that all the keys up to this are already in the
database. Since we're using multiple writers it can happen that another
thread has not yet written key=500 and verifying these keys will cause the
test failure.

Do you think my assumption is correct?

Thanks,
Peter

Re: Problem with IntegrationTestRegionReplicaReplication

[Peter Somogyi]

I'm using hbase based on 1.2 version.

On Sat, Jun 17, 2017 at 4:00 PM, Devaraj Das <d...@hortonworks.com> wrote:

> Peter which version of HBase are tou testing with?
>
>
>
>
> On Thu, Jun 15, 2017 at 11:57 PM -0700, "Peter Somogyi" <
> psomo...@cloudera.com<mailto:psomo...@cloudera.com>> wrote:
>
>
> I tried with those parameters but the test still failed.
> I noticed that some of the rows were not replicated to the replicas just
> after I called flush manually. I think memstore replication is not working
> on my system even though it is enabled in the configuration.
> I will look into it today.
>
> On Fri, Jun 16, 2017 at 7:09 AM, Devaraj Das  wrote:
>
> > Peter, do have a look at IntegrationTestRegionReplicaReplication.java ..
> > At the top of the file, the ways to specify the options are documented ..
> > You need to add something like -DIntegrationTestRegionReplicaR
> eplication.read_delay_ms
> > ..
> > 
> > From: Josh Elser
> > Sent: Thursday, June 15, 2017 10:40 AM
> > To: dev@hbase.apache.org
> > Subject: Re: Problem with IntegrationTestRegionReplicaReplication
> >
> > I'd start trying a read_delay_ms=6, region_replication=2,
> > num_keys_per_server=5000, num_regions_per_server=5 with a maybe 10's of
> > reader and writer threads.
> >
> > Again, this can be quite dependent on the kind of hardware you have.
> > You'll definitely have to tweak ;)
> >
> > On 6/15/17 4:44 AM, Peter Somogyi wrote:
> > > Thanks Josh and Devaraj!
> > >
> > > I will try to increase the timeouts. Devaraj, could you share the
> > > parameters you used for this test which worked?
> > >
> > > On Thu, Jun 15, 2017 at 6:44 AM, Devaraj Das
> > wrote:
> > >
> > >> That sounds about right, Josh. Peter, in our internal testing we have
> > seen
> > >> this test failing and increasing timeouts (look at the test code
> > options to
> > >> do with increasing timeout) helped quite some.
> > >> 
> > >> From: Josh Elser
> > >> Sent: Wednesday, June 14, 2017 3:17 PM
> > >> To: dev@hbase.apache.org
> > >> Subject: Re: Problem with IntegrationTestRegionReplicaReplication
> > >>
> > >> On 6/14/17 3:53 AM, Peter Somogyi wrote:
> > >>> Hi,
> > >>>
> > >>> As one of my first task with HBase I started to look into
> > >>> why IntegrationTestRegionReplicaReplication fails. I would like to
> get
> > >> some
> > >>> suggestions from you.
> > >>>
> > >>> I noticed when I run the test using normal cluster or minicluster I
> get
> > >> the
> > >>> same error messages: "Error checking data for key [null], no data
> > >>> returned". I looked into the code and here are my conclusions.
> > >>>
> > >>> There are multiple threads writing data parallel which are read by
> > >> multiple
> > >>> reader threads simultaneously. Each writer gets a portion of the keys
> > to
> > >>> write (e.g. 0-2000) and these keys are added to a ConstantDelayQueue.
> > >>> The reader threads get the elements (e.g. key=1000) from the queue
> and
> > >>> these reader threads assume that all the keys up to this are already
> in
> > >> the
> > >>> database. Since we're using multiple writers it can happen that
> another
> > >>> thread has not yet written key=500 and verifying these keys will
> cause
> > >> the
> > >>> test failure.
> > >>>
> > >>> Do you think my assumption is correct?
> > >>
> > >> Hi Peter,
> > >>
> > >> No, as my memory serves, this is not correct. Readers are not made
> aware
> > >> of keys to verify until the write occur plus some delay. The delay is
> > >> used to provide enough time for the internal region replication to
> take
> > >> effect.
> > >>
> > >> So: primary-write, pause, [region replication happens in background],
> > >> add updated key to read queue, reader gets key from queue verifies the
> > >> value on a replica.
> > >>
> > >> The primary should always have seen the new value for a key. If the
> test
> > >> is showing that a replica does not see the result, it's either a
> timing
> > >> issue (you need to give a larger delay for HBase to perform the region
> > >> replication) or a bug in the region replication framework itself. That
> > >> said, if you can show that you are seeing what you describe, that
> sounds
> > >> like the test framework itself is broken :)
> > >>
> > >>
> > >>
> > >>
> > >
> >
> >
> >
>
>

Re: [VOTE] First hbase-2.0.0-alpha-3 Release Candidate is available

[Peter Somogyi]

+1 (non-binding)

- verified signature
- verified checksum
- checked licenses
- built from source on tag 2.0.0-alpha-3RC0.2
- build hbase from src tarball
- checked UI
- basic functionalities of hbase shell

On Mon, Sep 18, 2017 at 1:22 PM, ashish singhi 
wrote:

> +1(non-binding)
>
> Built tar from source code
> Verified few commands on shell and other few from Java API, all looks ok
> Verified audit logs
> Verified HBase replication on a single node cluster, checked metrics
> Checked zk_dump and web UI, looks ok
>
> Regards,
> Ashish
>
> -Original Message-
> From: saint@gmail.com [mailto:saint@gmail.com] On Behalf Of Stack
> Sent: 15 September 2017 23:33
> To: HBase Dev List 
> Cc: d...@phoenix.apache.org
> Subject: [VOTE] First hbase-2.0.0-alpha-3 Release Candidate is available
>
> The first release candidate for HBase 2.0.0-alpha-3 is up at:
>
>   https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0-alpha-3RC0/
>
> Maven artifacts are available from a staging directory here:
>
>   https://repository.apache.org/content/repositories/orgapachehbase-1175
>
> All was signed with my key at y 8ACC93D2  lookup?op=get=0x9816C7FC8ACC93D2>
>
> I tagged the RC as
> 2.0.0-alpha-3RC0.2 (a5c8461ca87d6324f16ffd126b765146fdd5315a)
>
> hbase-2.0.0-alpha-3 is our third alpha release on our march toward an
> hbase-2.0.0. It includes all that was in previous alphas (new assignment
> manager, offheap read/write path, in-memory compactions, etc.), but had a
> focus on polishing our public API: old API that had been deprecated since
> hbase-1.0.0 or before was purged and new API was added with sympathetic
> deprecation of the previous. Along the Admin plane, incompatible changes
> were unavoidable; you will not be able to administer a hbase2 cluster using
> an hbase1 client (see adjacent "[DISCUSS] hbase-2.0.0 compatibility
> expectations" thread for discussion and see [1] for current list of
> Incompatibles).
>
> What is here will be our public API for 2.0.0 unless we get pushback from
> our gracious downstreamers. Please try it out. Shout now if you find a
> problem so we can fix it before we get to beta.
>
> Alpha-3 does not have the final version of our Coprocessor API. Finishing
> the Coprocessor API for hbase-2.0.0 is the topic of our last planned alpha,
> 2.0.0-alpha-4. The Coprocessor API changes pretty radically in hbase-2.0.0
> (though Coprocessor Endpoints will continue to work across an upgrade). See
> [2] for why and why it was unavoidable. Input now from Coprocessor API
> users before alpha-4 would be especially effective (I've cc'd our Phoenix
> brothers and sisters toward this end).
>
> hbase-2.0.0-alpha-3RC0 is a rough cut ('alpha'), not-for-production
> preview of what hbase-2.0.0 will look like. It is meant for devs and
> downstreamers to test drive and flag us early if we messed up anything
> ahead of our rolling GAs.
>
> The list of features addressed in 2.0.0 so far can be found here [3].
> There are about 2700+. The list of ~500 fixes in 2.0.0 exclusively can be
> found here [3].
>
> I've updated our overview doc. on the state of 2.0.0 [6] but JIRA 2.0.0
> label [5] has undergone extensive weeding and presents a fairly good
> picture on what is yet to do before we 2.0.0. Check it out.
>
> Please take it for a spin and vote on whether it ok to put out as our
> first alpha (bar is low for an 'alpha'). Let the VOTE be open for 72 hours
> (Sunday)
>
> Thanks,
> St.Ack
>
> 1. Current list of Incompatibles:
> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_
> ktczrlKHK8N4SZzs/edit#heading=h.723jjn18p2jr
> 2. Why CPs are Incompatible:
> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_
> ktczrlKHK8N4SZzs/edit#heading=h.9k7mjbauv0wj
> 3. goo.gl/Gcrp4f
> 4. goo.gl/6dPqzG
> 5. https://issues.apache.org/jira/projects/HBASE/versions/12327188
> 6.
> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_
> ktczrlKHK8N4SZzs/
>

Re: [DISCUSS] HBASE-18978 Table and AsyncTable alignment

[Peter Somogyi]

Thanks Duo and Ted!

bq. The coprocessor related methods are in RawAsyncTable interface.
I'll add this to the spreadsheet.

bq. I think that changing the return type only doesn't have to be done in
this iteration.
I agree, I will skip this part.

On Fri, Oct 13, 2017 at 5:48 PM, Ted Yu <yuzhih...@gmail.com> wrote:

> Nice spreadsheet, Peter.
>
> w.r.t. Different return types, I took a look at the discussion
> on HBASE-18912.
>
> I think that changing the return type only doesn't have to be done in this
> iteration.
>
> Cheers
>
> On Fri, Oct 13, 2017 at 5:16 PM, Peter Somogyi <psomo...@cloudera.com>
> wrote:
>
> > Hi,
> >
> > I started to work on HBASE-18978 (Align the methods in Table and
> > AsyncTable) and I would appreciate some feedback from you.
> >
> > To make it simpler to compare the differences between Table and
> AsyncTable
> > I put together a spreadsheet.
> > https://docs.google.com/spreadsheets/d/15DdDp3Yljlb_
> > Mrd3BQuoyzqnhomJhTM8bHvmEa6t6Jc/edit?usp=sharing
> >
> > I categorized them into the following groups:
> >
> > * RPC timeouts
> > - Both interfaces have the same functionality, however, in AsyncTable the
> > TimeUnit can be set for each method.
> > - The getRpcTimeout is deprecated in Table from version 2.0.0, but it is
> > not deprecated in AsyncTable.
> > We can make the RPC timeout handling aligned in the 2 interfaces. My
> > recommendation is to go with the ones in AsyncTable.
> >
> > * Coprocessor
> > - Methods that are related to Coprocessors are only available in Table.
> > What is the reason for this?
> >
> > * List with xAll operations
> > - We have the ability to run operation (get, delete, put, batch) in batch
> > mode using a List input parameter in both interfaces. AsyncTable has
> > additional methods called xAll(List) (e.g. getAll) where we have the same
> > operations but the whole operation fails if there are any failures.
> > - The methods related to {exists} differ from the previous operations. To
> > compare it with {get}:
> > Table | AsyncTable
> > 
> > ---
> > Result get(Get get)   | CompletableFuture
> > get(Get get)
> > Result[] get(List gets) | List<CompletableFuture
> >
> > get(List gets)
> > -|
> > CompletableFuture<List> getAll(List gets)
> > 
> > ---
> > boolean exists(Get get)| CompletableFuture
> > exists(Get get)
> > boolean[] existsAll(List gets)  | List<CompletableFuture>
> > exists(List gets)
> > -|
> > CompletableFuture<List> existsAll(List gets)
> > Should we align these methods?
> >
> > - Method {batch} is also similar to these operations, however, the
> > signature is different between Table and AsyncTable interfaces.
> > Additionally, Table had a method {batchCallback} which is missing from
> > AsyncTable.
> >
> > * Checks
> > Check and mutate methods are way different. Table has checkAndx methods
> > (some of them are deprecated), but AsyncTable has an interface called
> > CheckAndMutateBuilder and these kind of operations are handled through
> > that.
> >
> > * Scan
> > Both interfaces include getScanner methods with the same signature.
> > Additionally, AsyncTable has {scan} and {scanAll} methods which are not
> > part of Table interface.
> >
> > * Different return types
> > There are 2 methods that does the same in the 2 interfaces but have
> > different return types. The ones in Table return with an array and the
> ones
> > from AsyncTable return with a List. HBASE-18912 is a similar issue on
> Admin
> > interface. Changing only return type is difficult. Do we need to deal
> with
> > this problem?
> >
> > Thanks,
> > Peter
> >
>

[DISCUSS] HBASE-18978 Table and AsyncTable alignment

[Peter Somogyi]

Hi,

I started to work on HBASE-18978 (Align the methods in Table and
AsyncTable) and I would appreciate some feedback from you.

To make it simpler to compare the differences between Table and AsyncTable
I put together a spreadsheet.
https://docs.google.com/spreadsheets/d/15DdDp3Yljlb_Mrd3BQuoyzqnhomJhTM8bHvmEa6t6Jc/edit?usp=sharing

I categorized them into the following groups:

* RPC timeouts
- Both interfaces have the same functionality, however, in AsyncTable the
TimeUnit can be set for each method.
- The getRpcTimeout is deprecated in Table from version 2.0.0, but it is
not deprecated in AsyncTable.
We can make the RPC timeout handling aligned in the 2 interfaces. My
recommendation is to go with the ones in AsyncTable.

* Coprocessor
- Methods that are related to Coprocessors are only available in Table.
What is the reason for this?

* List with xAll operations
- We have the ability to run operation (get, delete, put, batch) in batch
mode using a List input parameter in both interfaces. AsyncTable has
additional methods called xAll(List) (e.g. getAll) where we have the same
operations but the whole operation fails if there are any failures.
- The methods related to {exists} differ from the previous operations. To
compare it with {get}:
Table | AsyncTable
---
Result get(Get get)   | CompletableFuture
get(Get get)
Result[] get(List gets) | List
get(List gets)
-|
CompletableFuture getAll(List gets)
---
boolean exists(Get get)| CompletableFuture
exists(Get get)
boolean[] existsAll(List gets)  | List
exists(List gets)
-|
CompletableFuture existsAll(List gets)
Should we align these methods?

- Method {batch} is also similar to these operations, however, the
signature is different between Table and AsyncTable interfaces.
Additionally, Table had a method {batchCallback} which is missing from
AsyncTable.

* Checks
Check and mutate methods are way different. Table has checkAndx methods
(some of them are deprecated), but AsyncTable has an interface called
CheckAndMutateBuilder and these kind of operations are handled through that.

* Scan
Both interfaces include getScanner methods with the same signature.
Additionally, AsyncTable has {scan} and {scanAll} methods which are not
part of Table interface.

* Different return types
There are 2 methods that does the same in the 2 interfaces but have
different return types. The ones in Table return with an array and the ones
from AsyncTable return with a List. HBASE-18912 is a similar issue on Admin
interface. Changing only return type is difficult. Do we need to deal with
this problem?

Thanks,
Peter

Re: [DISCUSS] update our imports layout

[Peter Somogyi]

I like the layout you suggested Chia-Ping and also to check this in the
precommit run.
Shall we also add "not to use * imports" to the verification?

On Sun, Oct 1, 2017 at 9:09 AM, Chia-Ping Tsai  wrote:

> bq.  I guess you meant attention.
> You are right. sorry for the misspelling. ☹
>
> On 2017-10-01 23:33, Ted Yu  wrote:
> > bq. hold our attraction
> >
> > I guess you meant attention.
> >
> > The suggestions under Q1 are good.
> >
> >
> >
> > On Sun, Oct 1, 2017 at 8:27 AM, Chia-Ping Tsai 
> wrote:
> >
> > > hi folks,
> > >
> > > I noticed the code conflict occurs on the imports frequently. To
> resolve
> > > the conflict is a complete waste of time, so i feel it is time to
> update
> > > our imports layout and hold our attraction on it.
> > >
> > > The import layout is shown below. (see hbase_eclipse_formatter.xml)
> > > javax.*
> > > blank line
> > > java.*
> > > blank line
> > > import all other imports
> > > blank line
> > > import static all other imports
> > >
> > > Q1:
> > > As i see it, two updates should be considered.
> > > 1) Should we move the "import static" to the top? (It seems most of
> files
> > > have its static imports on the top)
> > > 2) Should we move the shaded class into new blocks?
> > >
> > > The new layout looks like this.
> > > import static all other imports
> > > blank line
> > > javax.*
> > > blank line
> > > java.*
> > > blank line
> > > org.*
> > > blank line
> > > org.apache.hadoop.hbase.shaded.*
> > > blank line
> > > import all other imports
> > >
> > > Q2:
> > > Should we check the import layout before committing? Perhaps we can
> > > address this in the HBASE-18438. The issue try to add the check of
> unused
> > > imports
> > >
> > > Any suggestions? Thanks.
> > > --
> > > Chia-Ping
> > >
> > >
> >
>

Re: [VOTE] hbase-thirdparty project, first release candidate 1.0.1RC0

[Peter Somogyi]

+1 (non-binding)

Checksum, signature good.
Built hbase pointing to staging repo.

I agree with Mike's LICENSE and CHANGES suggestions.

Peter

On Thu, Aug 24, 2017 at 12:46 AM, Stack  wrote:

> This is a minor update to hbase-thirdparty, our little side project of
> relocated popular includes such as guava, protobuf, and netty (See [1] for
> more on what hbase-thirdparty is).
>
> hbase-thirdparty 1.0.1RC0 is available at:
>
>  https://dist.apache.org/repos/dist/dev/hbase/hbase-thirdparty/1.0.1RC0/
>
> Maven artifacts are available in the staging repository:
>
>  https://repository.apache.org/content/repositories/orgapachehbase-1174
>
> Artifacts are signed with 8ACC93D2 which is at the tail of our KEYS file
> http://www-us.apache.org/dist/hbase/KEYS.
>
> I tagged this RC as 1.0.1RC0 at in the hbase-thirdparty repo at
> e07089bee6f51aec65de932b302894507903bd6e
> https://git-wip-us.apache.org/repos/asf/hbase-thirdparty
>
> This minor release includes three fixes:
>
> HBASE-18321 [hbase-thirdparty] Fix generation of META-INF/DEPENDENCIES to
> include dependency list and versions
> HBASE-18666 [hbase-thirdparty] Exclude errorprone annotation
> com.google.errorprone.annotations.CanIgnoreReturnValue
> HBASE-18313 [hbase-thirdparty] Produce src jars/tgz
>
> The first fixes an issue found during VOTE on 1.0.0, the second makes it so
> errorprone build will work back in mainline hbase, and the third has us
> producing src jars when we publish to maven.
>
> VOTE lasts 72 hours.
>
> Thanks,
> St.Ack
>
>
> 1. http://hbase.apache.org/book.html#thirdparty
>

Re: QA test runs timed out for branch-1.x

[Peter Somogyi]

Chia-Ping Tsai and I was experimenting on HBASE-19019. The successful QA
test was for branch-2 or branch-1.x ignoring TestThriftServerCmdLine.
HBASE-19019 is about QA failure on hbase-thrift module.

On Sat, Oct 21, 2017 at 11:54 PM, 张铎(Duo Zhang) 
wrote:

> https://builds.apache.org/job/PreCommit-HBASE-Build/9305/console
>
> But this one ended successfully? It is also for HBASE-19019.
>
> 2017-10-21 23:12 GMT+08:00 Ted Yu :
>
> > Hi,
> > Looking at https://builds.apache.org/job/PreCommit-HBASE-Build/ , there
> > were 4 timed out builds (HBASE-19019, etc).
> > It seems each of them was for branch-1.x
> >
> > Toward the end of console log, I saw:
> >
> > *11:34:26* Build timed out (after 360 minutes). Marking the build as
> > failed.*11:34:26* ERROR: Could not install
> > JDK_1_7_LATEST__HOME*11:34:26*
> > java.lang.NullPointerException*11:34:26*at
> > hudson.plugins.toolenv.ToolEnvBuildWrapper$1.buildEnvVars(
> > ToolEnvBuildWrapper.java:46)*11:34:26*
> > at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.
> > java:887)*11:34:26*
> > at hudson.plugins.build_timeout.operations.
> > WriteDescriptionOperation.perform(WriteDescriptionOperation.
> > java:65)*11:34:26*
> > at hudson.plugins.build_timeout.BuildTimeoutWrapper$
> > EnvironmentImpl$TimeoutTimerTask.doRun(BuildTimeoutWrapper.java:144)*
> > 11:34:26*
> > at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:51)*11:
> > 34:26*
> > at java.util.TimerThread.mainLoop(Timer.java:555)*11:34:26*
>  at
> > java.util.TimerThread.run(Timer.java:505)*11:34:26* ERROR: Could not
> > install MAVEN_LATEST__HOME*11:34:26*
> > java.lang.NullPointerException*11:34:26*at
> > hudson.plugins.toolenv.ToolEnvBuildWrapper$1.buildEnvVars(
> > ToolEnvBuildWrapper.java:46)*11:34:26*
> > at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.
> > java:887)*11:34:26*
> > at hudson.plugins.build_timeout.operations.
> > WriteDescriptionOperation.perform(WriteDescriptionOperation.
> > java:65)*11:34:26*
> > at hudson.plugins.build_timeout.BuildTimeoutWrapper$
> > EnvironmentImpl$TimeoutTimerTask.doRun(BuildTimeoutWrapper.java:144)*
> > 11:34:26*
> > at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:51)*11:
> > 34:26*
> > at java.util.TimerThread.mainLoop(Timer.java:555)*11:34:26*
>  at
> > java.util.TimerThread.run(Timer.java:505)*11:34:27* Build was aborted
> >
> >
> > Could this be related to recent changes (under dev-support) ?
> >
> >
> > Thanks
> >
>

Re: [VOTE] First hbase-2.0.0-alpha4 Release Candidate is available

[Peter Somogyi]

+1 (non-binding), found 1 issue.

Checked signatures, sums - OK
Built from source tar and git tag (Oracle JDK 1.8.0_151, Maven 3.5.2) - OK
Rat check - OK
Starting standalone server from bin tar - OK
LTT with 1M rows - OK
LICENSE, NOTICE - OK

Problem:
Starting standalone server after building from src tar fails: same problem
that Guanghao Zhang had. HBASE-18705

On Wed, Nov 1, 2017 at 3:17 PM, Stack  wrote:

> The first release candidate for HBase 2.0.0-alpha4 is up at:
>
>   https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0-alpha4RC0/
>
> Maven artifacts are available from a staging directory here:
>
>   https://repository.apache.org/content/repositories/orgapachehbase-1178
>
> All was signed with my key at 8ACC93D2 [1]
>
> I tagged the RC as 2.0.0-alpha4RC0
> (5c4b985f89c99cc8b0f8515a4097c811a0848835)
>
> hbase-2.0.0-alpha4 is our fourth alpha release along our march toward
> hbase-2.0.0. It includes all that was in previous alphas (new assignment
> manager, offheap read/write path, in-memory compactions, etc.), but had a
> focus on "Coprocessor Fixup": We no longer pass Coprocessors
> InterfaceAudience.Private parameters and we cut down on the access and
> ability to influence hbase core processing (See [2] on why the radical
> changes in Coprocessor Interface). If you are a Coprocessor developer or
> have Coprocessors to deploy on hbase-2.0.0, we need to hear about your
> experience now before we make an hbase-2.0.0 beta.
>
> hbase-2.0.0-alpha4 is a rough cut ('alpha'), not-for-production preview of
> what hbase-2.0.0 will look like. It is meant for devs and downstreamers to
> test drive and flag us early if we messed up anything ahead of our rolling
> GAs.
>
> The list of features addressed in 2.0.0 so far can be found here [3]. There
> are thousands. The list of ~2k+ fixes in 2.0.0 exclusively can be found
> here [4] (My JIRA JQL foo is a bit dodgy -- forgive me if mistakes).
>
> I've updated our overview doc. on the state of 2.0.0 [6]. 2.0.0-beta-1 will
> be our next release. Its theme is the "Finishing up 2.0.0" release. Here is
> the list of what we have targeted for beta-1 [5]. Check it out. Shout if
> there is anything missing. We may do a 2.0.0-beta-2 if a need. We'll see.
>
> Please take this alpha for a spin especially if you are a Coprocessor
> developer or have a Coprocessor you want to deploy on hbase-2.0.0. Please
> vote on whether it ok to put out this RC as our first alpha (bar is low for
> an 'alpha' -- e.g. CHANGES.txt has not been updated). Let the VOTE be open
> for 72 hours (Saturday)
>
> Thanks,
> Your 2.0.0 Release Manager
>
> 1. http://pgp.mit.edu/pks/lookup?op=get=0x9816C7FC8ACC93D2
> 2. Why CPs are Incompatible:
> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_
> ktczrlKHK8N4SZzs/edit#heading=h.9k7mjbauv0wj
> 3. https://goo.gl/scYjJr
> 4. https://goo.gl/tMHkYS
> 5. https://issues.apache.org/jira/projects/HBASE/versions/12340861
> 6.
> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_
> ktczrlKHK8N4SZzs/
>

Re: [VOTE] The first HBase 1.4.0 release candidate (RC0) is available

[Peter Somogyi]

+1

checksum, signature: ok
tests: ok
LTT with 1M rows: ok
basic operations from shell: ok
rat check: ok

On Thu, Dec 7, 2017 at 5:40 AM, Andrew Purtell  wrote:

> The first HBase 1.4.0​ release candidate (RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.0RC0/ and Maven
> artifacts are available in the temporary repository
> https://repository.apache.org/content/repositories/orgapachehbase-1185/ .
>
> The git tag corresponding to the candidate is '1.4.0RC0' (3d571827cb).
>
> A detailed source and binary compatibility report for this release is
> available for your review at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.0RC0/
> hbase-1.3.1-1.4.0RC0_compatibility_report.html
> ​. All reported compatibility issues should comply with policy but please
> review them carefully.
>
> A list of the ​652 issues resolved in this release can be found at
> https://s.apache.org/OErT .
>
> Please try out the candidate and vote +1/0/-1.
>
> This vote will be open for at least 72 hours. Unless objection I will try
> to close it ​Monday December 18, 2017 if we have sufficient votes.
>
> Prior to making this announcement I made the following preflight checks to
> 1.4.0RC0 (3d571827cb):
>
>- RAT check passes (7u80)
>- Unit test suite passes (8u131)
>- LTT load 1M rows with 100% verification and 20% updates (8u131)
>- PE randomWrite, randomRead, scanRange100 (8u131)
>- 100M rows ITBLL (8u131)
>
> Between now and when I want to close the vote I'll write up human readable
> release notes for the release announcement as promised. I also have agreed
> to run a scale ITBLL test, a performance comparison with 1.2 using YCSB, a
> performance comparison with 1.2 using PE, and an analysis of code and
> allocation hot spot changes from 1.2, all of which I will publish when
> available and factor in to my vote.
>
>
> --
> Best regards,
> Andrew
>

Re: [VOTE] First release candidate for HBase 1.1.13 (RC0) is available

[Peter Somogyi]

+1 (non binding)

Signature, sum: ok
Able to start from bin: ok
Check basic functionalities: ok
LTT with 1M rows: ok
Built from source: ok (8u151)
Rat check: ok


In the logs I saw this line. Source code repository URL looks incorrect.
2017-12-04 10:13:27,028 INFO  [main] util.VersionInfo: Source code
repository *git://diocles.local/Volumes/hbase-1.1.13/hbase* revision=
c64bf8a9f35352cd504f2b8f4b02f9148cf45ab6

On Fri, Dec 1, 2017 at 7:31 AM, Nick Dimiduk  wrote:

> I'm happy to announce the first release candidate of HBase 1.1.13
> (HBase-1.1.13RC0) is available for download at
> *https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.13RC0/
> *.
>
> This is to be the final release from branch-1.1.
>
> Maven artifacts are available in the staging repository
> *https://repository.apache.org/content/repositories/orgapachehbase-1182
> *
>
> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
> available in the Apache keys directory https://people.apache.org/keys
> /committer/ndimiduk.asc and in our KEYS file
> http://www-us.apache.org/dist/
> hbase/KEYS.
>
> There's also a signed tag for this release at
> *https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=
> 16a04e6629e614c7900c443f3a29cdba92dd7b7e
>  16a04e6629e614c7900c443f3a29cdba92dd7b7e>*
>
> The detailed source and binary compatibility report vs 1.1.12 has been
> published for your review, at
> *https://home.apache.org/~ndimiduk/1.1.12_1.1.13RC0_compat_report.html
> *
>
> HBase 1.1.13 is the thirteenth and final patch release in the HBase 1.1
> line, continuing on the theme of bringing a stable, reliable database to
> the Hadoop and NoSQL communities. This release includes over 40 resolved
> issues since the 1.1.12 release; the majority of these changes are to build
> tooling rather than the product itself. Notable product correctness fixes
> include HBASE-18665 and HBASE-19052.
>
> The full list of fixes included in this release is available at
> *https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12310753=12341346
>  projectId=12310753=12341346>*
> and
> and in the CHANGES.txt file included in the distribution.
>
> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
> Friday, 2017-12-08 as to whether we should release these artifacts as HBase
> 1.1.13.
>
> Thanks,
> Nick
>

Fixed PreCommit runs

[Peter Somogyi]

Hi,

Recently we had some docker issues with our PreCommit jobs. HBASE-20689 was
pushed to all active branches. If your PreCommit job recently failed due to
this issue please resubmit your patch to trigger a new test run.

Thanks,
Peter

Re: [VOTE] First release candidate for hbase-2.0.1 (RC0) is available

[Peter Somogyi]

+1 (non-binding)

Checksums, signatures - OK
Build from source - OK
Unit tests - OK
Rat check - OK
Started in pseudo-distributed mode - OK
Shell CRUD operations - OK
Web UI / LOGs - OK

On Wed, Jun 13, 2018 at 11:15 PM Stack  wrote:

> The first release candidate for Apache HBase 2.0.1 is available for
> download and testing. This is a bug fix release with 70+ commits [1].
> Release notes are available here [2].
>
> Artifacts are available here:
>
>  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.1RC0/
>
> Corresponding convenience artifacts for maven use are in the staging
> repository:
>
>  https://repository.apache.org/content/repositories/orgapachehbase-1222
>
> All artifacts are signed with my code signing key, 8ACC93D2, which is
> also in the project KEYS file:
>
> http://www.apache.org/dist/hbase/KEYS
>
> These artifacts correspond to commit ref
>
> 987f7b6d37c2fcacc942cc66e5c5122aba8fdfbe
>
> which has been tagged as 2.0.1RC0.
>
> Please take a few minutes to verify the release and vote on releasing it:
>
> [ ] +1 Release these artifacts as Apache HBase 2.0.1
> [ ] -1 Do not release this package because ...
>
> This VOTE thread will remain open for at least 72 hours.
>
> Thanks,
> S
>
> 1. https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.1RC0/CHANGES.md
> 2. https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.1RC0/
> RELEASENOTES.md
>

Re: [VOTE] First release candidate for HBase 1.2.6.1 (RC0) is available

[Peter Somogyi]

+1 (non-binding)

Checksums, signatures: OK
Apache rat check: OK
Tarballs' content: OK
Build from source: OK
Unit tests: NOK
TestTableLockManager is flaky
Web UI: OK
Shell w/ basic commands: OK

Thanks,
Peter

Running org.apache.hadoop.hbase.master.TestTableLockManager
Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 70.798 sec
<<< FAILURE! - in org.apache.hadoop.hbase.master.TestTableLockManager
testReapAllTableLocks(org.apache.hadoop.hbase.master.TestTableLockManager)
Time elapsed: 0.099 sec  <<< ERROR!
org.apache.hadoop.hbase.exceptions.LockTimeoutException: Timed out
acquiring writelock for table:table4for:zero timeout after 0 ms.
at
org.apache.hadoop.hbase.master.TableLockManager$ZKTableLockManager$TableLockImpl.acquire(TableLockManager.java:282)
at
org.apache.hadoop.hbase.master.TestTableLockManager.testReapAllTableLocks(TestTableLockManager.java:283)

On Mon, Jun 4, 2018 at 8:46 AM Sean Busbey  wrote:

> Hi!
>
> The first release candidate for Apache HBase 1.2.6.1 is available for
> download and testing.
>
> Artifacts are available here:
>
> https://dist.apache.org/repos/dist/dev/hbase/1.2.6.1RC0/
>
> You can find the SHA512 of the artifacts as of this email at the end.
>
> Corresponding convenience artifacts for maven use are in the staging
> repository:
>
> https://repository.apache.org/content/repositories/orgapachehbase-1218/
>
> All artifacts are signed with my code signing key, 0D80DB7C, which is
> also in the project KEYS file:
>
> http://www.apache.org/dist/hbase/KEYS
>
> These artifacts correspond to commit ref
>
> 61297b5e3acf2a77606b59e0b6f0013c9dae0fbb
>
> which has been tagged as 1.2.6.1RC0 as a convenience.
>
> Please take a few minutes to verify the release and vote on releasing it:
>
> [ ] +1 Release these artifacts as Apache HBase 1.2.6.1
> [ ] -1 Do not release this package because ...
>
> This VOTE thread will remain open for at least 72 hours.
>
> -busbey
>
> as of this email the posted artifacts have the following SHA512.
>
> hbase-1.2.6.1-src.tar.gz: 02A44970 2614D148 7B2162A5 9AC23837 FC2583BC
> 068BC8D8
>   8FCB1C30 3FE38D2D 403727D5 E7103FF7 7FDF65B1
> 1F4DFF3D
>   7E9945BE A5A9453F 4FE0AE0A A56C28FE
>
> hbase-1.2.6.1-bin.tar.gz: EB473744 184430BE 55E8DAF2 A6450E2F 06281960
> 13D473D0
>   596779AB 2F1EEFBA 1BB76273 F1C48BCD FCAB1A33
> 2AFCB649
>   B0BC3EF8 B2756540 70E7E375 F5CFC43A
>

Re: [ANNOUNCE] New HBase committer Guangxu Cheng

[Peter Somogyi]

Congratulations!

On Mon, Jun 4, 2018 at 9:00 AM 张铎(Duo Zhang)  wrote:

> On behalf of the Apache HBase PMC, I am pleased to announce that Guangxu
> Cheng has accepted the PMC's invitation to become a committer on the
> project. We appreciate all of Guangxu's generous contributions thus far and
> look forward to his continued involvement.
>
> Congratulations and welcome, Guangxu!
>

Re: [VOTE] Apache HBase 1.3.2.1RC0

[Peter Somogyi]

+1 (non-binding)

Checksums, signatures: OK
Apache rat check: OK
Tarballs' content: OK
Build from source: OK
Unit tests: NOK
TestHBaseFsck failed once
Web UI: OK
Shell w/ basic commands: OK

Environment:
Debian 8
Apache Maven 3.5.3
Java version: 1.8.0_171, vendor: Oracle Corporation

[ERROR] Tests run: 57, Failures: 1, Errors: 0, Skipped: 1, Time elapsed:
421.433 s <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
[ERROR]
testHbckReportReplicaLingeringSplitParent(org.apache.hadoop.hbase.util.TestHBaseFsck)
Time elapsed: 8.434 s  <<< FAILURE!
java.lang.AssertionError: expected:<[]> but was:<[NOT_DEPLOYED,
NOT_DEPLOYED, HOLE_IN_REGION_CHAIN]>
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testHbckReportReplicaLingeringSplitParent(TestHBaseFsck.java:230)

On Sat, Jun 2, 2018 at 11:26 PM Josh Elser  wrote:

> Hi,
>
> Please vote to approve the following as Apache HBase 1.3.2.1
>
> https://dist.apache.org/repos/dist/dev/hbase/1.3.2.1RC0/
>
> Per usual, there is a source release as well as a convenience binary
>
> This is built with JDK7 from the commit:
>
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=commit;h=bf25c1cb7221178388baaa58f0b16a408e151a69
> (there is a corresponding tag "1.3.2.1RC0" for convenience)
>
> hbase-1.3.2.1-bin.tar.gz: 1D CB 27 E0 B0 56 28 B8  BE C7 41 03 2E B5 D3 31
> hbase-1.3.2.1-src.tar.gz: 47 99 46 3C 2B E2 59 9B  5B 8B 2F 16 81 53 6B FE
> hbase-1.3.2.1-bin.tar.gz: 16EB62DA D4EA40F6 DD8747CF 6A49678E D1A4A53E
> B3A9E67D
>C53A89F1 471D1DC5 5147E5CA D1AED8B0 B22A01F5
> C1F6F6CA
>4B4E9562 61CDA9B6 91D94C16 26593AFB
> hbase-1.3.2.1-src.tar.gz: 63C55C02 DB27461E 2C006758 329EC21E E14823E3
> 9080105B
>43FA6EF2 05BD81A3 D526E2AC 6EAE0FE9 1C3103F4
> 20B8457F
>3C94EF73 5B3CB18C 85B7E0AB 4311CAA4
>
> This vote will be open for at least 72 hours (2018/06/05 2130 UTC).
>
> - Josh (on behalf of the HBase PMC)
>

Re: [VOTE] First release candidate for HBase 1.2.6.1 (RC0) is available

[Peter Somogyi]

On Mon, Jun 4, 2018 at 4:05 PM Sean Busbey  wrote:

> On Mon, Jun 4, 2018 at 6:54 AM, Peter Somogyi  wrote:
> > +1 (non-binding)
> >
> > Checksums, signatures: OK
> > Apache rat check: OK
> > Tarballs' content: OK
> > Build from source: OK
> > Unit tests: NOK
> > TestTableLockManager is flaky
> > Web UI: OK
> > Shell w/ basic commands: OK
> >
> > Thanks,
> > Peter
> >
> > Running org.apache.hadoop.hbase.master.TestTableLockManager
> > Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 70.798
> sec
> > <<< FAILURE! - in org.apache.hadoop.hbase.master.TestTableLockManager
> >
> testReapAllTableLocks(org.apache.hadoop.hbase.master.TestTableLockManager)
> > Time elapsed: 0.099 sec  <<< ERROR!
> > org.apache.hadoop.hbase.exceptions.LockTimeoutException: Timed out
> > acquiring writelock for table:table4for:zero timeout after 0 ms.
> > at
> >
> org.apache.hadoop.hbase.master.TableLockManager$ZKTableLockManager$TableLockImpl.acquire(TableLockManager.java:282)
> > at
> >
> org.apache.hadoop.hbase.master.TestTableLockManager.testReapAllTableLocks(TestTableLockManager.java:283)
> >
>
> Thanks for checking on things Peter! What's your maven + Java versions?


I used Maven 3.5.3, java 1.8.0_171 on Mac OS.

Re: Failure: HBase Generate Website

[Peter Somogyi]

The connection was lost to the build server. I manually retriggered the job
which succeeded.
https://builds.apache.org/job/hbase_generate_website/1357/

On Sun, May 27, 2018 at 4:43 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> Build status: Failure
>
> The HBase website has not been updated to incorporate HBase commit
> ${CURRENT_HBASE_COMMIT}.
>
> See https://builds.apache.org/job/hbase_generate_website/1356/console

Re: [VOTE] The third release candidate for HBASE 2.0.0 (RC2) is available

[Peter Somogyi]

+1 (non-binding)

Checksum, signature: ok
Rat check: ok
Build from source (8_163): ok
Start from bin in pseudo distributed mode w/ HDFS: ok
LTT 1M rows: ok
Simple shell commands: ok
Test RSGroup: ok
Web UI: ok
REST server: ok

NOTE: Using the new JDK (8_171) TestSaslFanOutOneBlockAsyncDFSOutput fails.
It is due to new feature called 'Enhanced KeyStore Mechanisms'[1]
introduced in this JDK release. The bug is actually not in HBase but
Hadoop: see HDFS-13494.

[1]
http://www.oracle.com/technetwork/java/javase/8u171-relnotes-430.html#JDK-8189997


On Mon, Apr 23, 2018 at 7:10 AM, Stack  wrote:

> The third release candidate for Apache HBase 2.0.0 is available for
> downloading and testing.
>
> Artifacts are available here:
>
>  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC2/
>
> Maven artifacts are available in the staging repository at:
>
> https://repository.apache.org/content/repositories/orgapachehbase-1213
>
> All artifacts are signed with my signing key 8ACC93D2, which is also
> in the project KEYS file at
>
>  http://www.apache.org/dist/hbase/KEYS
>
> These artifacts were tagged 2.0.0RC2 at hash 7483b111e4da77adbfc8062b3b22cb
> e7c2cb91c1
>
> Please review 'Upgrading from 1.x to 2.x' in the bundled HBase 2.0.0
> Reference Guide before installing or upgrading for a list of
> incompatibilities, major changes, and notable new features. Be aware that
> according to our adopted Semantic Versioning guidelines[1], we've allow
> ourselves to make breaking changes in this major version release. For
> example, Coprocessors will need to be recast to fit more constrained CP
> APIs and a rolling upgrade of an hbase-1.x install to hbase-2.x without
> downtime is (currently) not possible. That said, a bunch of effort has been
> expended mitigating differences; a hbase-1.x client can perform DML against
> an hbase-2 cluster. A
> bundled compatibility report showing difference from 1.2.6 may be of help
> [3].
>
> For the full list of ~6k issues addressed, see [2]. There are also
> CHANGES.md and RELEASENOTES.md in the root directory of the source tarball.
>
> Please take a few minutes to verify the release and vote on releasing it:
>
> [ ] +1 Release this package as Apache HBase 2.0.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
> This VOTE will run for one week and close Sunday, April 29, 2018 @ 21:00
> PST.
>
> Thanks to the myriad who have helped out with this release,
> Your 2.0.0 Release Manager
>
> 1. http://hbase.apache.org/2.0/book.html#hbase.versioning.post10
> 2. https://s.apache.org/zwS9
> 3.
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC2/compatibiliity_report_1.2.6vs2.0.0RC2.html
>

Re: Two master branches?

[Peter Somogyi]

Something is still not correct with the branches in the apache repo.
After git pull the master branch points to f3c563fc00 but in log
apache/master is still on 298dc0c626. The pull does the following all the
time, working directory is clean. apache/Master also points to 298dc0c626.

$ git pull
>From https://github.com/apache/hbase
   298dc0c626..f3c563fc00  master -> apache/master
 * [new branch]Master -> apache/Master
Already up to date.

$ git status
On branch master
Your branch is ahead of 'apache/master' by 7 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

$ git lg
* f3c563fc00 - (HEAD -> master) HBASE-19837 Flakey TestRegionLoad (2 hours
ago) 
* 27d00f5861 - HBASE-19794 TestZooKeeper hangs (20 hours ago) 
* 7fe4aa6fe4 - HBASE-19828 Flakey
TestRegionsOnMasterOptions.testRegionsOnAllServers (2 days ago) 
* 11d6e6b1e6 - HBASE-19829 hadoop-minicluster pulls
zookeeper:test-jar:tests 3.4.6 (2 days ago) 
* 4bfdcaa3f3 - HBASE-19823 Make RawCellBuilderFactory
LimitedPrivate.UNITTEST (2 days ago) 
* 579586c697 - HBASE-19827 Addendum for Flakey TestAssignmentManager Don't
clear old location from RTP... (2 days ago) 
* c66b42fd9d - Revert "HBASE-19827 Addendum for Flakey
TestAssignmentManager" Premature commit. (3 days ago) 
* 298dc0c626 - (apache/master) HBASE-19822 Override cancel(boolean) in
LogCleaner (Addendum) (3 days ago) 


On Sat, Jan 20, 2018 at 7:50 AM, Stack  wrote:

> Looks like Master was added a few days ago, by mistake is my guess:
> https://github.com/apache/hbase/branches
>
> Kill it after ensuring master has all its commits?
>
> Shout if you want me to do it sir.
>
> S
>
> On Fri, Jan 19, 2018 at 2:50 PM, Apekshit Sharma 
> wrote:
>
> > I see following three branches:
> >   remotes/apache/HEAD -> apache/master
> >   remotes/apache/Master
> >   remotes/apache/master
> >
> > Was "Master" always there?
> >
> > --
> >
> > -- Appy
> >
>

Re: [VOTE] The first HBase 1.4.1 release candidate (RC0) is available

[Peter Somogyi]

The tests failed in localhost mode when executed from maven. I've just
checked some integration tests now on 1.4.0 and it fails there as well, so
it not a regression. I'm OK with a +1 on this RC.

Peter

On Mon, Jan 29, 2018 at 5:52 PM, Andrew Purtell <andrew.purt...@gmail.com>
wrote:

> Are the integration test failures from when it runs in localhost mode? I
> think these are long term test issues present since 1.3. Or, is this new in
> 1.4.1? If these also have the same result with 1.4.0, indicating no new
> regression, would you consider changing your vote?
>
> > On Jan 29, 2018, at 6:54 AM, Peter Somogyi <psomo...@cloudera.com>
> wrote:
> >
> > 0
> >
> > - RAT check: OK
> > - Signatures, checksums: OK
> > - Build from src: OK
> > - Start standalone from src and bin, run shell commands: OK
> > - LTT 1M rows: OK
> > - Web UI, logs: OK
> > - Ran full test suite: passes except integration tests
> >
> > I had failures in IntegrationTestRpcClient, IntegrationTestMTTR,
> > IntegrationTestBigLinkedListWithVisibility and
> > IntegrationTestWithCellVisibilityLoadAndVerify. All other tests passed
> for
> > me.
> >
> >> On Thu, Jan 25, 2018 at 3:45 AM, Andrew Purtell <apurt...@apache.org>
> wrote:
> >>
> >> The first HBase 1.4.1 release candidate (RC0) is available for download
> at
> >> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.1RC0/ and Maven
> >> artifacts are available in the temporary repository
> >> https://repository.apache.org/content/repositories/orgapachehbase-1194
> .
> >>
> >> The git tag corresponding to the candidate is '1.4.1RC0' (4b25debc83).
> >>
> >> A detailed source and binary compatibility report for this release is
> >> available for your review at
> >> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.1RC0/
> >> compat-check-report.html
> >> .
> >>
> >> A list of the 38 issues resolved in this release can be found at
> >> https://s.apache.org/tx1w .
> >>
> >> Please try out the candidate and vote +1/0/-1.
> >>
> >> This vote will be open for at least 72 hours. Unless objection I will
> try
> >> to close it Friday February 2, 2018 if we have sufficient votes.
> >>
> >> Prior to making this announcement I made the following preflight checks:
> >>
> >>   - RAT check passes (7u80)
> >>   - Unit test suite passes 10 of 10 iterations (8u131)
> >>   - LTT load 1M rows with 100% verification and 20% updates (8u131)
> >>   - PE sequentialWrite, sequentialRead, randomWrite, randomRead,
> >>   scanRange100 (8u131)
> >>
> >>
> >> --
> >> Best regards,
> >> Andrew
> >>
> >> Words like orphans lost among the crosstalk, meaning torn from truth's
> >> decrepit hands
> >>   - A23, Crosstalk
> >>
>

Re: [VOTE] The first HBase 1.4.1 release candidate (RC0) is available

[Peter Somogyi]

0

- RAT check: OK
- Signatures, checksums: OK
- Build from src: OK
- Start standalone from src and bin, run shell commands: OK
- LTT 1M rows: OK
- Web UI, logs: OK
- Ran full test suite: passes except integration tests

I had failures in IntegrationTestRpcClient, IntegrationTestMTTR,
IntegrationTestBigLinkedListWithVisibility and
IntegrationTestWithCellVisibilityLoadAndVerify. All other tests passed for
me.

On Thu, Jan 25, 2018 at 3:45 AM, Andrew Purtell  wrote:

> The first HBase 1.4.1 release candidate (RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.1RC0/ and Maven
> artifacts are available in the temporary repository
> https://repository.apache.org/content/repositories/orgapachehbase-1194 .
>
> The git tag corresponding to the candidate is '1.4.1RC0' (4b25debc83).
>
> A detailed source and binary compatibility report for this release is
> available for your review at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.1RC0/
> compat-check-report.html
> .
>
> A list of the 38 issues resolved in this release can be found at
> https://s.apache.org/tx1w .
>
> Please try out the candidate and vote +1/0/-1.
>
> This vote will be open for at least 72 hours. Unless objection I will try
> to close it Friday February 2, 2018 if we have sufficient votes.
>
> Prior to making this announcement I made the following preflight checks:
>
>- RAT check passes (7u80)
>- Unit test suite passes 10 of 10 iterations (8u131)
>- LTT load 1M rows with 100% verification and 20% updates (8u131)
>- PE sequentialWrite, sequentialRead, randomWrite, randomRead,
>scanRange100 (8u131)
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: Precommit OutOfMemoryError

[Peter Somogyi]

The Nightly build started to fail as well.
branch-2: https://builds.apache.org/job/HBase%20Nightly/job/branch-2/223/
artifact/output-jdk8-hadoop2/patch-unit-root.txt

On Tue, Jan 30, 2018 at 11:01 AM, Peter Somogyi <psomo...@cloudera.com>
wrote:

> Hi,
>
> Recent precommit jobs are failing with OutOfMemoryError or "[ERROR] unable
> to create new native thread".
> https://builds.apache.org/job/PreCommit-HBASE-Build/11250/
> artifact/patchprocess/patch-mvninstall-root.txt
> <https://builds.apache.org/job/PreCommit-HBASE-Build/11250/artifact/patchprocess/patch-mvninstall-root.txt>
> https://builds.apache.org/job/PreCommit-HBASE-Build/11251/
> artifact/patchprocess/patch-unit-hbase-server.txt
>
> Can someone with access rights to Apache Jenkins take a look?
>
> Thanks,
> Peter
>

Precommit OutOfMemoryError

[Peter Somogyi]

Hi,

Recent precommit jobs are failing with OutOfMemoryError or "[ERROR] unable
to create new native thread".
https://builds.apache.org/job/PreCommit-HBASE-Build/11250/artifact/patchprocess/patch-mvninstall-root.txt

https://builds.apache.org/job/PreCommit-HBASE-Build/11251/artifact/patchprocess/patch-unit-hbase-server.txt

Can someone with access rights to Apache Jenkins take a look?

Thanks,
Peter

Re: [VOTE] The first HBase 1.4.2 release candidate (RC0) is available

[Peter Somogyi]

+1 (non-binding)

Checked signature, sums
Rat check
Web UI: split, merge tables
Shell basic functionalities
LTT 1M rows
Build with full test suite
PE 1M rows
Basic operations from java client


On Fri, Feb 16, 2018 at 10:46 PM, Andrew Purtell 
wrote:

> The first HBase 1.4.2 release candidate (RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.2RC0/ and Maven
> artifacts are available in the temporary repository
> https://repository.apache.org/content/repositories/orgapachehbase-1195/ .
>
> The git tag corresponding to the candidate is '1.4.2RC0' (9519ec2ead).
>
> A detailed source and binary compatibility report for this release is
> available for your review at https://dist.apache.org/repos/
> dist/dev/hbase/hbase-1.4.2RC0/compat-check-report.html .
>
> A list of the 19 issues resolved in this release can be found at
> https://s.apache.org/aGcb .
>
> Please try out the candidate and vote +1/0/-1.
>
> This vote will be open for at least 72 hours. Unless objection I will try
> to close it Friday February 23, 2018 if we have sufficient votes.
>
> Prior to making this announcement I made the following preflight checks:
>
>- RAT check passes (7u80)
>- Unit test suite passes (8u131)
>- LTT load 1M rows with 100% verification and 20% updates (8u131)
>- PE sequentialWrite, sequentialRead, randomWrite, randomRead,
>scanRange100 (8u131)
>- ITBLL Loop 1 100M rows (8u131)
>
>
> --
> Best regards,
> Andrew
>

Re: [VOTE] The second HBase 1.4.2 release candidate (RC1) is available

[Peter Somogyi]

+1 (non-binding)

signatures, checksum
LTT 1M rows
PE 1M rows
unit tests
basic functionalities on web ui and shell
tested custom info port
simple operations from java client

Thanks,
Peter

On Fri, Feb 23, 2018 at 12:56 AM, Andrew Purtell 
wrote:

> The close date will be *Wednesday* February 28, 2018.
>
> On Thu, Feb 22, 2018 at 3:55 PM, Andrew Purtell 
> wrote:
>
> > The second HBase 1.4.2 release candidate (RC1) is available for download
> > at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.2RC1/ and
> Maven
> > artifacts are available in the temporary repository
> > https://repository.apache.org/content/repositories/orgapachehbase-1196/
> .
> >
> > The git tag corresponding to the candidate is '1.4.2RC1' (b4ec89059c).
> > Note this is different from branch-1.4 by one commit because we had an
> > intervening commit between tag and push (08b9939974, HBASE-20016) while I
> > was running tests. The only difference is the CHANGES.txt update for
> > 1.4.2RC1 is placed ahead of the commit for HBASE-20016, but does not
> > mention it, which is fine, because 1.4.2RC1 does not contain HBASE-20016.
> >
> > A detailed source and binary compatibility report for this release is
> > available for your review at https://dist.apache.org/repos/
> > dist/dev/hbase/hbase-1.4.2RC1/compat-check-report.html .
> >
> > A list of the 22 issues resolved in this release can be found at
> > https://s.apache.org/aGcb .
> >
> > Please try out the candidate and vote +1/0/-1.
> >
> > This vote will be open for at least 72 hours. Unless objection I will try
> > to close it Thursday February 28, 2018 if we have sufficient votes.
> >
> > Prior to making this announcement I made the following preflight checks:
> >
> >- RAT check passes (7u80)
> >- Unit test suite passes (8u131)
> >- LTT load 1M rows with 100% verification and 20% updates (8u131)
> >- PE sequentialWrite, sequentialRead, randomWrite, randomRead,
> >scanRange100 (8u131)
> >- ITBLL Loop 1 100M rows (8u131)
> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[Peter Somogyi]

Thank you very much everyone!

On Thu, Feb 22, 2018 at 8:08 PM, Sean Busbey <bus...@apache.org> wrote:

> On behalf of the Apache HBase PMC, I am pleased to announce that Peter
> Somogyi has accepted the PMC's invitation to become a committer on the
> project.
>
> We appreciate all of Peter's great work thus far and look forward to
> continued involvement.
>
> Please join me in congratulating Peter!
>

Re: [VOTE] The first HBase 1.4.6 release candidate (RC0) is available

[Peter Somogyi]

+1 (non-binding)

Signatures, checksums correct
RAT check passed (8u171)
Unit tests passed (8u171)
LTT 1M rows passed
Web UI looks correct
Simple shell commands work

Thanks for the release,
Peter

On Wed, Jul 25, 2018 at 8:36 PM Andrew Purtell  wrote:

> The first HBase 1.4.6 release candidate (RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.6RC0/ and Maven
> artifacts are available in the temporary repository
> https://repository.apache.org/content/repositories/orgapachehbase-1226/ .
>
> The git tag corresponding to the candidate is '1.4.6RC0' (a55bcbd4fc).
>
> A detailed source and binary compatibility report for this release is
> available for your review at
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.6RC0/compat-check-report.html
> . There is an added method to the LimitedPrivate interface ReplicationPeer
> which will not cause binary compatibility issues but will require source
> changes at recompilation. This type of additive change is allowed. The
> internal utility class Base64 has been made private and so the related
> changes are allowed.
>
> A list of the 34 issues resolved in this release can be found at
> https://s.apache.org/kolm .
>
> Please try out the candidate and vote +1/0/-1.
>
> This vote will be open for at least 72 hours. Unless objection I will try
> to close it Monday July 30, 2018 if we have sufficient votes.
>
> Prior to making this announcement I made the following preflight checks:
>
> RAT check passes (7u80)
> Unit test suite passes (7u80)
> LTT load 1M rows with 100% verification and 20% updates (8u172)
> ITBLL Loop 1 500M rows with serverKilling monkey (8u172)
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [ANNOUNCE] New HBase committer Zach York

[Peter Somogyi]

Congratulations!

On Wed, Mar 7, 2018 at 9:43 AM, Huaxiang Sun  wrote:

> Congratulations, Zach!
>
>
> > On Mar 7, 2018, at 9:26 AM, Umesh Agashe  wrote:
> >
> > Congratulations, Zach!
> >
> > On Wed, Mar 7, 2018 at 8:40 AM, Ted Yu  wrote:
> >
> >> Congratulations, Zach !
> >>
> >> On Wed, Mar 7, 2018 at 8:27 AM, Sean Busbey  wrote:
> >>
> >>> On behalf of the Apache HBase PMC, I am pleased to announce that Zach
> >>> York has accepted the PMC's invitation to become a committer on the
> >>> project.
> >>>
> >>> We appreciate all of Zach's great work thus far and look forward to
> >>> continued involvement.
> >>>
> >>> Please join me in congratulating Zach!
> >>>
> >>
>
>

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/
> >>
> >>
>

Re: [ANNOUNCE] Please welcome Ashish Singhi to the HBase PMC

[Peter Somogyi]

Congratulations!

On Wed, Feb 28, 2018 at 8:13 AM, Ted Yu  wrote:

> Congratulations, Ashish.
>
> On Wed, Feb 28, 2018 at 7:55 AM, Sean Busbey  wrote:
>
> > On behalf of the Apache HBase PMC I am pleased to announce that Ashish
> > Singhi has accepted our invitation to become a PMC member on the
> > Apache HBase project. We appreciate Ashish stepping up to take more
> > responsibility in the HBase project.
> >
> > As a reminder, if anyone would like to nominate another person as a
> > committer or PMC member, even if you are not currently a committer or
> > PMC member, you can always drop a note to priv...@hbase.apache.org to
> > let us know!
> >
> > - busbey
> >
>

Re: [ANNOUNCE] Please welcome Mike Drob to the HBase PMC

[Peter Somogyi]

Congratulations!

On Wed, Feb 28, 2018 at 10:40 AM, Esteban Gutierrez 
wrote:

> Excellent! congratulations, Mike!
>
> --
> Cloudera, Inc.
>
>
> On Wed, Feb 28, 2018 at 10:38 AM, Tamás Pénzes 
> wrote:
>
> > Congrats Mike!
> >
> > On Wed, Feb 28, 2018 at 8:13 AM, Ted Yu  wrote:
> >
> > > Congratulations, Mike !
> > >
> > > On Wed, Feb 28, 2018 at 7:54 AM, Sean Busbey 
> wrote:
> > >
> > > > On behalf of the Apache HBase PMC I am pleased to announce that Mike
> > > > Drob has accepted our invitation to become a PMC member on the Apache
> > > > HBase project. We appreciate Mike stepping up to take more
> > > > responsibility in the HBase project.
> > > >
> > > >
> > > > As a reminder, if anyone would like to nominate another person as a
> > > > committer or PMC member, even if you are not currently a committer or
> > > > PMC member, you can always drop a note to priv...@hbase.apache.org
> to
> > > > let us know!
> > > >
> > > > - busbey
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Tamás **Pénzes* | Engineering Manager
> > e. tam...@cloudera.com
> > cloudera.com 
> >
> > [image: Cloudera] 
> >
> > [image: Cloudera on Twitter]  [image:
> > Cloudera on Facebook]  [image:
> Cloudera
> > on LinkedIn] 
> > --
> >
>

Re: [ANNOUNCE] Please welcome Guanghao Zhang to the HBase PMC

[Peter Somogyi]

Congratulations!

On Wed, Feb 28, 2018 at 8:13 AM, Ted Yu  wrote:

> Congratulations, Guanghao !
>
> On Wed, Feb 28, 2018 at 7:55 AM, Sean Busbey  wrote:
>
> > On behalf of the Apache HBase PMC I am pleased to announce that
> > Guanghao Zhang has accepted our invitation to become a PMC member on
> > the Apache HBase project. We appreciate Guanghao stepping up to take
> > more responsibility in the HBase project.
> >
> > As a reminder, if anyone would like to nominate another person as a
> > committer or PMC member, even if you are not currently a committer or
> > PMC member, you can always drop a note to priv...@hbase.apache.org to
> > let us know!
> >
> > - busbey
> >
>

Re: Missing jira number

[Peter Somogyi]

I haven't noticed the missing jira id when committing. Fixed now.

On Wed, Mar 14, 2018 at 11:39 AM, 张铎(Duo Zhang) 
wrote:

> commit 641c87ddf93f88758b5db0b5b506ec53dc826a62
> Author: Sakthi 
> Date:   Tue Mar 13 23:40:09 2018 -0700
>
> Fixed typo in Required Java Version error message while building HBase
>
> Signed-off-by: Umesh Agashe 
>

Re: 1.3.2 status is incorrect in JIRA

[Peter Somogyi]

Thanks for the clarification Andrew!

On Wed, Mar 14, 2018 at 5:26 PM, Andrew Purtell <andrew.purt...@gmail.com>
wrote:

> The RMs release in JIRA for voting on release candidates. It helps with
> assembling CHANGES and makes it less likely someone will set a fix version
> to something in the process of release.
>
> When I do this I set the release date to the expected conclusion of
> voting. The date can be adjusted if more than one candidate and voting
> period is required.
>
> I'm not sure all RMs do it this way but I do and advised Francis to do the
> same for 1.3.2.
>
>
> > On Mar 14, 2018, at 9:20 AM, Peter Somogyi <psomo...@apache.org> wrote:
> >
> > Hi,
> >
> > I noticed that 1.3.2 is marked as "released" in JIRA but it is still an
> > unreleased version. What is the reason for that?
> >
> > Thanks,
> > Peter
>

1.3.2 status is incorrect in JIRA

[Peter Somogyi]

Hi,

I noticed that 1.3.2 is marked as "released" in JIRA but it is still an
unreleased version. What is the reason for that?

Thanks,
Peter

[DISCUSS] RowCounter duplication

[Peter Somogyi]

Hi,

Currently we have 2 RowCounter tools in our
repository: o.a.h.h.mapreduce.RowCounter and o.a.h.h.mapred.RowCounter.
None of them is marked as deprecated but mapred.RowCounter was deprecated
in pre-HBase 1 releases and the annotation was eventually removed
in HBASE-11178.

Do we still want to or need to keep both versions? The mapred tool is not
documented in refguide and the command's usage is minimal. The
mapreduce.RowCounter tool also has more features.

Thanks,
Peter

Re: [DISCUSS] RowCounter duplication

[Peter Somogyi]

Thanks for bringing this up Chia-Ping Tsai. Yes, the question can be more
general whether we need to support the old API.

On Tue, Apr 10, 2018 at 7:49 PM, Chia-Ping Tsai <chia7...@apache.org> wrote:

> There are other tools having two versions - o.a.h.h.mapreduce and
> o.a.h.h.mapred
> It seems to me the question is "should hbase support old MR APIs ?' Given
> that hadoop 3.0 doesn't mark old MR APIs deprecated, we should keep them in
> hbase? Or we can deprecate them in hbase-2+ in order to remove them in the
> future?
>
> On 2018/04/10 16:02:07, Peter Somogyi <psomo...@apache.org> wrote:
> > Hi,
> >
> > Currently we have 2 RowCounter tools in our
> > repository: o.a.h.h.mapreduce.RowCounter and o.a.h.h.mapred.RowCounter.
> > None of them is marked as deprecated but mapred.RowCounter was deprecated
> > in pre-HBase 1 releases and the annotation was eventually removed
> > in HBASE-11178.
> >
> > Do we still want to or need to keep both versions? The mapred tool is not
> > documented in refguide and the command's usage is minimal. The
> > mapreduce.RowCounter tool also has more features.
> >
> > Thanks,
> > Peter
> >
>

Re: [VOTE] First release candidate for HBase 2.0.0 (RC0) is available

[Peter Somogyi]

-1

Tests under hbase-rsgroup fail in setup phase. It is related to
HBASE-20224, some addendums were not backported to branch-2.0 which causes
the failure. I'm reopening HBASE-20224 and backport 2 missing commits.

On Fri, Apr 13, 2018 at 3:54 PM, Jean-Marc Spaggiari <
jean-m...@spaggiari.org> wrote:

> Exactly what I was looking for! Thanks Sean!
>
> 2018-04-13 9:37 GMT-04:00 Sean Busbey :
>
> > Hi JMS!
> >
> > Current flaky results for branch-2.0, generated today AFAICT:
> >
> > https://builds.apache.org/view/H-L/view/HBase/job/HBase-
> > Find-Flaky-Tests-branch2.0/lastSuccessfulBuild/artifact/
> >
> > you can look at the "dashboard.html" artifact for a human usable idea
> > of what we think is broken.
> >
> > you can fetch the excludes file to get a pattern you can pass to Maven.
> >
> >
> > On Fri, Apr 13, 2018 at 7:40 AM, Jean-Marc Spaggiari
> >  wrote:
> > > Do we have a list of tests that we know will not pass this release?
> > >
> > > I got those failures so far, but since I want to run multiple runs, I
> > want
> > > to make sure to exclude the un-stable tests.
> > >
> > > TestAssignmentManagerMetrics.testRITAssignmentManagerMetrics:152
> Metrics
> > > Should be equal expected:<1> but was:<0>
> > > TestReplicationSmallTests.testDisableEnable:198 Replication wasn't
> > disabled
> > > TestReplicationSmallTests.testSimplePutDelete:168->
> TestReplicationBase.
> > runSimplePutDeleteTest:266
> > > Waited too much time for put replication
> > > TestClientOperationTimeout.setUp:99 » SocketTimeout callTimeout=500,
> > > callDurat...
> > >
> > > Thanks,
> > >
> > > JMS
> > >
> > >
> > > 2018-04-13 0:19 GMT-04:00 Yu Li :
> > >
> > >> bq. I'd imagine that if the difference were large, then yes, it should
> > >> be a blocker
> > >> -- or we as a community can decide to work on it in a follow-on
> release
> > >> making perf a priority (say, 2.1.0).
> > >> I see, thanks for the clarification boss, makes sense.
> > >>
> > >> Best Regards,
> > >> Yu
> > >>
> > >> On 13 April 2018 at 06:02, Stack  wrote:
> > >>
> > >> > On Thu, Apr 12, 2018 at 1:47 PM, Stack  wrote:
> > >> >
> > >> > > On Tue, Apr 10, 2018 at 2:50 PM, Sean Busbey 
> > >> wrote:
> > >> > >
> > >> > >> no compat report in the RC directory. does that mean we won't
> have
> > one
> > >> > >> in the dist area?
> > >> > >>
> > >> > >>
> > >> > >> not a blocker; we've been inconsistent on it in prior releases,
> but
> > >> > >> the trend seemed to be towards including it.
> > >> > >>
> > >> > >>
> > >> > >
> > >> > > HBASE-18622 has current state of compatibility compare. Let me do
> a
> > new
> > >> > > run and add it to the RC dir.
> > >> > >
> > >> >
> > >> > I just added
> > >> > https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> > >> > compat-check-v1.2.6-v2.0.0.report.html
> > >> >
> > >> > Thanks,
> > >> > S
> > >> >
> > >> >
> > >> >
> > >> > > St.Ack
> > >> > >
> > >> > >
> > >> > >
> > >> > >>
> > >> > >> On Tue, Apr 10, 2018 at 3:47 PM, Stack  wrote:
> > >> > >> > The first release candidate for Apache HBase 2.0.0 is available
> > for
> > >> > >> > downloading and testing.
> > >> > >> >
> > >> > >> > Artifacts are available here:
> > >> > >> >
> > >> > >> >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC0/
> > >> > >> >
> > >> > >> > Maven artifacts are available in the staging repository at:
> > >> > >> >
> > >> > >> >  https://repository.apache.org/content/repositories/
> > >> > orgapachehbase-1209
> > >> > >> >
> > >> > >> > All artifacts are signed with my signing key 8ACC93D2, which is
> > also
> > >> > >> > in the project KEYS file at
> > >> > >> >
> > >> > >> >  http://www.apache.org/dist/hbase/KEYS
> > >> > >> >
> > >> > >> > These artifacts were tagged 2.0.0RC0 at
> > >> > >> > hash 011dd2dae33456b3a2bcc2513e9fdd29de23be46
> > >> > >> >
> > >> > >> > Please review 'Upgrading from 1.x to 2.x' in the bundled HBase
> > 2.0.0
> > >> > >> > Reference Guide before installing or upgrading for a list of
> > >> > >> > incompatibilities, major changes, and notable new features. Be
> > aware
> > >> > >> that
> > >> > >> > according to our adopted Semantic Versioning guidelines[1],
> we've
> > >> > allow
> > >> > >> > ourselves to make breaking changes in this major version
> release.
> > >> For
> > >> > >> > example, Coprocessors will need to be recast to fit more
> > constrained
> > >> > CP
> > >> > >> > APIs and a rolling upgrade of an hbase-1.x install to hbase-2.x
> > >> > without
> > >> > >> > downtime is (currently) not possible. That said, a bunch of
> > effort
> > >> has
> > >> > >> been
> > >> > >> > expended mitigating differences; a hbase-1.x client can perform
> > DML
> > >> > >> against
> > >> > >> > an hbase-2 cluster.
> > >> > >> >
> > >> > >> > For the full list of ~6k issues addressed, see [2]. There are
> > also
> > >> > >> > CHANGES.md and RELEASENOTES.md in the root 

Re: [DISCUSS] RowCounter duplication

[Peter Somogyi]

Thanks Chia-Ping Tsai and Sean Busbey for the inputs. Looks like we need to
keep both versions.

Regards,
Peter

On Wed, Apr 11, 2018 at 5:25 PM, Sean Busbey <bus...@apache.org> wrote:

> So long as we're still supporting integration with the Apache Hadoop
> MapReduce project including versions that have both the old and new
> api, I think we need to support both.
>
> On Wed, Apr 11, 2018 at 7:15 AM, Peter Somogyi <psomo...@apache.org>
> wrote:
> > Thanks for bringing this up Chia-Ping Tsai. Yes, the question can be more
> > general whether we need to support the old API.
> >
> > On Tue, Apr 10, 2018 at 7:49 PM, Chia-Ping Tsai <chia7...@apache.org>
> wrote:
> >
> >> There are other tools having two versions - o.a.h.h.mapreduce and
> >> o.a.h.h.mapred
> >> It seems to me the question is "should hbase support old MR APIs ?'
> Given
> >> that hadoop 3.0 doesn't mark old MR APIs deprecated, we should keep
> them in
> >> hbase? Or we can deprecate them in hbase-2+ in order to remove them in
> the
> >> future?
> >>
> >> On 2018/04/10 16:02:07, Peter Somogyi <psomo...@apache.org> wrote:
> >> > Hi,
> >> >
> >> > Currently we have 2 RowCounter tools in our
> >> > repository: o.a.h.h.mapreduce.RowCounter and
> o.a.h.h.mapred.RowCounter.
> >> > None of them is marked as deprecated but mapred.RowCounter was
> deprecated
> >> > in pre-HBase 1 releases and the annotation was eventually removed
> >> > in HBASE-11178.
> >> >
> >> > Do we still want to or need to keep both versions? The mapred tool is
> not
> >> > documented in refguide and the command's usage is minimal. The
> >> > mapreduce.RowCounter tool also has more features.
> >> >
> >> > Thanks,
> >> > Peter
> >> >
> >>
>

Re: [ANNOUNCE] Please welcome Francis Liu to the HBase PMC

[Peter Somogyi]

Congrats Francis!

On Wed, Apr 11, 2018 at 10:03 PM, Andrew Purtell 
wrote:

> On behalf of the Apache HBase PMC I am pleased to announce that Francis
> Liu has accepted our invitation to become a PMC member on the Apache
> HBase project. We appreciate Francis stepping up to take more
> responsibility in the HBase project. He has been an active contributor to
> HBase for many years and recently took over responsibilities as branch RM
> for branch-1.3.
>
> Please join me in welcoming Francis to the HBase PMC!
>
> --
> Best regards,
> Andrew
>

Re: Idle thoughts on tooling around maintaining older branches

[Peter Somogyi]

I think we definitely need a tool like this! +1

On Wed, Apr 25, 2018 at 5:31 PM, Sean Busbey  wrote:

> I don't want to get stuck on the particulars of the specific jira, but
> take as an example HBASE-18842 "The hbase shell clone_snaphost command
> returns bad error message". This issue was fixed back in October, but
> only for 3.0.0-SNAPSHOT. It looks to me like a good candidate for
> earlier branches (and I've reopened it as I cherry pick it back): it's
> not marked incompatible, it is marked as a Bug, it has tests, it fixes
> some obviously incorrect behavior.
>
> makes me think we'd benefit from a periodic report that committers
> could check for things likely needed for backport to earlier branches.
> even something simple like "bug, not incompatible, has tests, clean
> cherry-pick" would make it easier for e.g. me to find issues like this
> when I have a few spare moments.
>
> If nothing else, I'd probably use this locally when reviewing things
> that could make it to earlier release lines. The marginal work to e.g.
> output HTML and get it into Jenkins is pretty small, if some other
> folks think it might also be useful. I'd want to document it in the
> ref guide, since I think lack of that kind of pointer limits the
> utility of these kinds of things.
>
> Before I add this to the list of things I start implementing in the
> between-spaces of other things I'm working on, what do folks think?
>

Re: Permission to add contributors

[Peter Somogyi]

Thanks Busbey!

On Mon, Mar 26, 2018 at 5:06 PM, Sean Busbey <bus...@apache.org> wrote:

> Hi Peter!
>
> I've updated the list of committers in JIRA to include you. Sorry for
> the process gap!
>
> You should now have the HBase project listed under "Jira
> administration" (I think it's the gear in the upper right)
>
> https://issues.apache.org/jira/plugins/servlet/project-
> config/HBASE/summary
>
> "Users and Roles" is where you add folks as contributors. Either
> "Contributors" or "Contributors 1" should work fine. The latter was
> added when we hit some scalability limit in an older version of JIRA
> around number of folks in a group.
>
> On Mon, Mar 26, 2018 at 9:32 AM, Peter Somogyi <psomo...@apache.org>
> wrote:
> > Hi,
> >
> > Could someone give me permission to add users as contributors to HBase
> JIRA?
> >
> > Thanks,
> > Peter
>

Permission to add contributors

[Peter Somogyi]

Hi,

Could someone give me permission to add users as contributors to HBase JIRA?

Thanks,
Peter

Re: [VOTE] HBase Thirdparty 2.1.0 RC0

[Peter Somogyi]

+1

Checksum, signature OK
Tar content OK
Build branch-2 with HBASE-20223 patch

Peter

On Wed, Mar 21, 2018 at 7:12 PM, Artem Ervits  wrote:

> +1 (non-binding)
> Verified signature and checksum: OK
> applied patch in HBASE-20223
> Built against branch-2.0, branch-2 and master: OK
> ran runSmallTests: NOK all fail on HTTP module but that's most likely
> problems with my environment.
>
> started in local mode: OK
> ran some shell commands: OK
>
> in the logs I see
>
> java.lang.NoSuchMethodException:
> org.apache.hadoop.fs.LocalFileSystem.setStoragePolicy(org.apache.
> hadoop.fs.Path,
> java.lang.String)
> at java.lang.Class.getDeclaredMethod(Class.java:2130)
> at
> org.apache.hadoop.hbase.util.CommonFSUtils.invokeSetStoragePolicy(
> CommonFSUtils.java:534)
> at
> org.apache.hadoop.hbase.util.CommonFSUtils.setStoragePolicy(
> CommonFSUtils.java:524)
> at
> org.apache.hadoop.hbase.fs.HFileSystem.setStoragePolicy(
> HFileSystem.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.hadoop.hbase.util.CommonFSUtils.invokeSetStoragePolicy(
> CommonFSUtils.java:563)
> at
> org.apache.hadoop.hbase.util.CommonFSUtils.setStoragePolicy(
> CommonFSUtils.java:524)
> at
> org.apache.hadoop.hbase.regionserver.HRegionFileSystem.setStoragePolicy(
> HRegionFileSystem.java:193)
> at
> org.apache.hadoop.hbase.regionserver.HStore.(HStore.java:254)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateHStore(HRegion.
> java:5510)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:998)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:995)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
>
> and confirmed that setStoragePolicy is not implemented in LocalFileSystem
> in Hadoop 2.7.4
>
>
>
> On Tue, Mar 20, 2018 at 7:02 PM, Stack  wrote:
>
> > +1
> >
> > Verified signature and hash.
> >
> > I see it updates pb but not guava? No harm. Next time.
> >
> > Built and installed jars locally from src tgz.
> >
> > Applied the HBASE-20223 patch to branch-2 and built... all seems good.
> >
> > Thanks for doing this,
> > S
> >
> >
> >
> > On Mon, Mar 19, 2018 at 4:15 PM, Josh Elser  wrote:
> >
> > > Hi,
> > >
> > > Please consider the following as the 2.1.0 release of Apache HBase
> > > Thirdparty.
> > >
> > > Source artifact, signatures, and checksums are available at
> > > https://dist.apache.org/repos/dist/dev/hbase/hbase-thirdpart
> > > y/hbase-thirdparty-2.1.0RC0/
> > >
> > > Git commit for the release candidate available at
> > > https://git-wip-us.apache.org/repos/asf?p=hbase-thirdparty.g
> > > it;a=commit;h=de125620dece453f49a56de5b328427dc534133f
> > >
> > > Maven repository available at https://repository.apache.org/
> > > content/repositories/orgapachehbase-1206
> > >
> > > This vote will remain open for at least 72 hours (~2018/03/22 2300
> GMT).
> > > HBASE-20223 has a patch for branch-2.0 which supports this thirdparty
> > > update (obligatory: have not run a full test suite locally with this
> > > change  yet).
> > >
> > > Here's my +1
> > >
> > > - Josh
> > >
> >
>

Re: [VOTE] First release candidate for HBase 1.3.2 (RC1) is available

[Peter Somogyi]

+1 (non-binding)

checked signatures, sums
built from source, ran unit tests
rat check
start from source and bin
basic shell commands
simple operations from basic java client
LTT with 1M rows

Thanks for the release,
Peter

On Tue, Mar 20, 2018 at 5:48 AM, Francis Liu  wrote:

> Hi,
>
> The second release candidate for Apache HBase 1.3.2 is available to
> download and testing.
>
> Artifacts are available here:
>
> *https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.2RC1/
> *
>
> Maven artifacts are available in the staging repository:
>
> *https://repository.apache.org/content/repositories/orgapachehbase-1205
> *
>
> All artifacts are signed with my code signing key D646D9F3, which is also
> in the project KEYS file at
>
> http://www.apache.org/dist/hbase/KEYS
>
> these artifacts correspond to commit hash
>
> 1bedb5bfbb5a99067e7bc54718c3124f632b6e17 tagged as 1.3.2RC1.
>
> HBase 1.3.2 is the second maintenance release in the HBase 1.3.z release
> line, continuing on the theme of bringing a stable, reliable database to
> the
> Hadoop and NoSQL communities. This release includes 256 resolved issues
> since 1.3.1 released 11 months ago.
>
> The full list of issues addressed is available at
>
> *https://s.apache.org/aMSp *
>
> and also in the CHANGES.txt file in the root directory of the source
> tarball.
>
> Please take a few minutes to verify the release and vote on
> releasing it:
>
> [ ] +1 Release this package as Apache HBase 1.3.2
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
> This Vote will run for one week and close Mon Mar 26, 2018 22:00 PST.
>
> Thanks
>

Update compatibility matrices

[Peter Somogyi]

Hi,

For the 1.4.8 vote I checked the Hadoop compatibility matrix [1] in the
reference guide which misses HBase-1.4.x release. I assume the supported
versions match with HBase-1.5.x, but I think we should add this explicitly
to the matrix. Are you aware of any differences compared to 1.5 release?

Related to this, would be good to update the JDK matrix as well, add the
missing versions and also include JDK 11 there since it just reached
general availability.

This is partially related to HBASE-21091 but I wanted to bring this up here
to reach wider audience.

Regards,
Peter

[1] https://hbase.apache.org/book.html#hadoop

Re: [VOTE] First release candidate for HBase 1.2.8 is available

[Peter Somogyi]

+1 (non-binding)

- signature, checksum: OK
- rat check: OK
- built from source (8u171, Maven 3.5.3): OK
- Unit tests (8u171, Maven 3.5.3): OK
- Shell basic functionalities: OK
- LTT 1M rows: OK
- Logs: OK

Thanks,
Peter

On Sat, Oct 13, 2018 at 12:19 AM Sean Busbey  wrote:

> The first release candidate for HBase 1.2.8 is available for download:
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.8RC0/
>
> Maven artifacts are also available in a staging repository at:
>
> https://repository.apache.org/content/repositories/orgapachehbase-1234/
>
> Artifacts are signed with my key (0D80DB7C) published in our KEYS
> file at http://www.apache.org/dist/hbase/KEYS
>
> The RC corresponds to the signed tag 1.2.8RC0, which currently points
>  to commit ref
>
> 56d38a088319413dc3a70e90b1b8e655c6a22340
>
> HBase 1.2.8 is the eigth maintenance release in the HBase 1.2 line,
> continuing on the theme of bringing a stable, reliable database to
> the Hadoop and NoSQL communities. This release includes about a half
> dozen bug fixes done in the month since 1.2.7.
>
> This release candidate contains the following incompatible changes,
> details in the release notes for the specific issue:
>
> * HBASE-21158 Empty qualifier cell should not be returned if it does not
>   match QualifierFilter
>
> The detailed source and binary compatibility report vs 1.2.7 has been
> published for your review, at:
>
> https://s.apache.org/hbase-1.2.8-rc0-compat-report
>
> The report shows no incompatibilities.
>
> Critical fixes include:
>
> * HBASE-21158 Empty qualifier cell should not be returned if it does not
>   match QualifierFilter
> * HBASE-21228 Memory leak since AbstractFSWAL caches Thread object and
>   never clean later
>
> The full list of fixes included in this release is available at:
>
> https://s.apache.org/hbase-1.2.8-jira-release-notes
>
> and in the CHANGES.txt file included in the distribution.
>
> Please try out this candidate and vote +1/-1 on whether we should
> release these artifacts as HBase 1.2.8.
>
> The VOTE will remain open for at least 72 hours. Given sufficient votes
> I would like to close it on October 18th, 2018.
>
> thanks!
>
> -busbey
>
> as of this email the posted artifacts have the following SHA512:
>
> hbase-1.2.8-bin.tar.gz:
> 29779F5C AAF7751F 68B404D5 FA53B77A 400D5D1A 6A98886F
> D7A2FC4F 367F00BA 5399FDD8 4EBA319F D40544AE D2D4877A
> 8380491B 9A1953D5 550A787F AD46B1A8
>
> hbase-1.2.8-src.tar.gz:
> E1643EBA 6513EF4F 34C75743 071614FC 28504931 C75D00F4
> A815292C AEF0ED96 C443EEED 11760A0A 9B8A3C51 5694559D
> FB242FD9 1E49CADE C3173C97 00FA4844
>
>

Re: [ANNOUNCE] New Committer: Balazs Meszaros

[Peter Somogyi]

Congratulations, Balázs!

On Thu, Oct 11, 2018 at 9:49 PM Sean Busbey  wrote:

> On behalf of the HBase PMC, I'm pleased to announce that Balazs
> Meszaros has accepted our invitation to become an HBase committer.
>
> Thanks for all your hard work Balazs; we look forward to more
> contributions!
>
> Please join me in extending congratulations to Balazs!
>

Re: [ANNOUNCE] Please welcome Zach York to the HBase PMC

[Peter Somogyi]

Congratulations!

On Thu, Oct 11, 2018 at 10:01 PM Sean Busbey  wrote:

> On behalf of the Apache HBase PMC I am pleased to announce that Zach
> York has accepted our invitation to become a PMC member on the Apache
> HBase project. We appreciate Zach stepping up to take more
> responsibility in the HBase project.
>
> Please join me in welcoming Zach to the HBase PMC!
>
> As a reminder, if anyone would like to nominate another person as a
> committer or PMC member, even if you are not currently a committer or
> PMC member, you can always drop a note to priv...@hbase.apache.org to
> let us know.
>

Re: [VOTE] First release candidate for hbase-2.1.1 (RC0) is available for download and test

[Peter Somogyi]

+1 (non-binding)

- Signature, checksum: OK
- Rat check: OK
- Build from source: OK
- Unit tests: OK
- LTT 1M rows: OK
- Master UI: OK
- Basic shell ops: OK

Thanks.
Peter

On Wed, Oct 31, 2018 at 3:21 AM Zach York 
wrote:

> +1
>
> - checked sums and sigs: Ok
> - Rat check: Ok
> - built from source: Ok (8u92)
> - Ran unit tests: Ok
> - Messed around with some basic shell commands: Ok
> - Loaded and read 1M rows with LTT: Ok
> - Sanity checked Web UI: Ok
>
> On Mon, Oct 29, 2018 at 9:11 PM Tak-Lon (Stephen) Wu 
> wrote:
>
> > +1 (non-binding)
> >
> >
> >
> >- checked sums and signatures: ok
> >- Rat check (8u181):  ok
> >   - mvn apache-rat:check
> >- built from source: ok (8u181)
> >   - mvn clean install -DskipTests
> >- Unit tests pass: ok (8u181)
> >   - mvn test -P runAllTests
> >   - [nit] TestRegionInfoDisplay.testRegionDetailsForDisplay failed
> >   once, but the second time it passed. the error was:
> >  -   [ERROR]
>  TestRegionInfoDisplay.testRegionDetailsForDisplay:78
> >  expected:<...:31 UTC 2018 (PT0.00[5]S ago), server=null> but
> > was:<...:31
> >  UTC 2018 (PT0.00[6]S ago), server=null>
> >   - 1 node HBase cluster test on Hadoop-2.8.4
> >   - WEB UI (8u181): checked Procedures/Process Metrics/Table
> >   Details/Home looks correct
> >   - basic HBase shell command
> >   [create/put/get/scan/flush/list/disable/drop] (8u181) : ok
> >   - Loaded 1M rows with LTT (8u181):  ok
> >  - hbase ltt -tn TestTable -write 10:16 -num_keys 100
> >  - hbase ltt -tn TestTable -read 100 -num_keys 100
> >
> > -Stephen
> >
> > On Mon, Oct 29, 2018 at 2:25 PM Stack  wrote:
> >
> > > I'm +1
> > >
> > > 10B ITBLL w/ slow deterministic just completed and verified on my
> little
> > > 6node cluster.
> > >
> > > Nightlies are pretty good. #540 is when the last commits for 2.1.1 went
> > in
> > > and ignoring the cancelled, ~50% passed:
> > >
> > >
> >
> https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-2.1/
> > >
> > > S
> > >
> > >
> > >
> > > On Sat, Oct 27, 2018 at 11:29 AM Stack  wrote:
> > >
> > > > The first release candidate for Apache HBase 2.1.1 (RC0) is available
> > > > for download and testing. This is a bug fix release with 180+ commits
> > [1]
> > > > since hbase-2.1.0. Release notes are available here [2]. The
> > > compatibility
> > > > report is at [3].
> > > >
> > > > Artifacts are available here:
> > > >
> > > >   https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.1RC0/
> > > >
> > > > Corresponding convenience artifacts for maven use are in the staging
> > > > repository:
> > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapachehbase-1235
> > > >
> > > > All artifacts are signed with my code signing key, 8ACC93D2, which is
> > > > also in the project KEYS file:
> > > >
> > > > http://www.apache.org/dist/hbase/KEYS
> > > >
> > > > These artifacts correspond to commit ref
> > > >
> > > >  b60a92d6864ef27295027f5961cb46f9162d7637
> > > >
> > > > which has been tagged as 2.1.1RC0.
> > > >
> > > > Nightlies are looking pretty good:
> > > >
> > > >
> > > >
> > >
> >
> https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-2.1/
> > > >
> > > > Please take a few minutes to verify the release and vote on releasing
> > it:
> > > >
> > > > [ ] +1 Release these artifacts as Apache HBase 2.1.1
> > > > [ ] -1 Do not release this package because ...
> > > >
> > > > This VOTE thread will remain open for at least 72 hours. It will
> close
> > > > for sure
> > > > Wednesday night (10/31).
> > > >
> > > > Thanks,
> > > > S
> > > >
> > > > 1.
> > > https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.1RC0/CHANGES.md
> > > > 2.
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.1RC0/RELEASENOTES.md
> > > >
> > > > P.S. Compatibility report is taking time. Will be back with it later
> > > today.
> > > >
> > >
> >
> >
> > --
> > Stephen Wu | Indiana University, Bloomington
> >
>

Re: [DISCUSS] Changing hadoop check versions in our hbase-personality?

[Peter Somogyi]

+1 Definitely valuable for HBase users to be aware of Hadoop CVEs.

Peter

On Tue, Nov 6, 2018 at 6:16 AM Stack  wrote:

> On Mon, Nov 5, 2018 at 10:09 AM Sean Busbey  wrote:
>
> > As of last week the Apache Hadoop project now keeps a public list of CVEs
> > that are public. (although it's currently limited to things from the last
> > year)
> >
> > https://hadoop.apache.org/cve_list.html
> >
> > Folks okay with linking to that page and updating Hadoop requirements for
> > the next minor releases in 1.y and 2.y to be versions without something
> > listed there?
> >
> >
> Sounds good.
>

>
> > What about dropping all the Hadoop 2's for HBase 3? (maybe a new thread?
> > :smile:)
> >
> >
> I wish.
>
> Yeah, another thread.
>
> S
>
>
> > On 2018/10/24 15:21:32, Sean Busbey  wrote:
> > > FYI HADOOP-15878 is tracking publishing impacted versions for the CVE
> > >
> > > On Tue, Oct 23, 2018 at 11:37 AM Sean Busbey 
> wrote:
> > > >
> > > > I can get behind more aggressively updating our dependencies to avoid
> > > > CVEs. I don't think we should do this in maintenance releases though.
> > > > Maintenance releases are meant to be extremely low risk for
> downstream
> > > > users. Despite our efforts to date upgrading a dependency is still
> > > > disruptive, especially when it's Hadoop. CVEs carry with them a
> needed
> > > > context for something to be an issue. That context almost never
> covers
> > > > all possible deployment scenarios and we should leave it to
> downstream
> > > > users to decide if the risk / reward trade off of justifies the
> > > > dependency update. Asking folks who think the risk is worth it to
> bump
> > > > up a minor HBase version or patch their deployment locally is a
> > > > reasonable trade off IMHO.
> > > >
> > > > I think I have the Hadoop PMC on board for publicizing impacted
> > > > versions on CVE-2018-8009 specifically. Give me a couple of days to
> > > > get that out in whatever form so that everyone in this discussion has
> > > > a more level field?
> > > > On Mon, Oct 22, 2018 at 9:07 PM 张铎(Duo Zhang)  >
> > wrote:
> > > > >
> > > > > I believe if there is a CVE for any of the dependencies we should
> > try to
> > > > > upgrade it, and IIRC there is an issue about finding these
> > dependencies out
> > > > > automatically. We haven't done this before does not mean ignoring a
> > CVE is
> > > > > the correct way, it is just because no one takes care of it...
> > > > >
> > > > > And the hadoop team has stated the versions which are vulnerable,
> all
> > > > > versions before 2.7.7, 2.8.5, 2.9.2(not released yet?), 3.0.3 and
> > 3.1.1.
> > > > > Not sure if they have published this out to the public, but as you
> > can see
> > > > > the url provided by me above, it is already public, so it does not
> > matter
> > > > > whether the hadoop team has published or not...
> > > > >
> > > > > Sean Busbey  于2018年10月23日周二 上午9:50写道：
> > > > >
> > > > > > Has the Hadoop PMC put out a public notice on the impact of that
> > CVE yet?
> > > > > > Specifically have they stated what versions are vulnerable? Are
> we
> > flagging
> > > > > > all versions impacted by it as "HBase says keep away"?
> > > > > >
> > > > > > Is there some reason this particular CVE especially impacts users
> > of HBase?
> > > > > > I presume not since we're talking about this on dev@ and in JIRA
> > instead
> > > > > > of
> > > > > > on private@.
> > > > > >
> > > > > > Why are we reacting to this CVE when we don't seem to react to
> any
> > other
> > > > > > Hadoop CVEs? Or is this the start of a change wrt that?
> > > > > >
> > > > > > What about other dependencies with open CVEs?
> > > > > >
> > > > > > On Mon, Oct 22, 2018, 20:33 张铎(Duo Zhang)  >
> > wrote:
> > > > > >
> > > > > > > See here:
> > > > > > >
> > > > > > > https://access.redhat.com/security/cve/cve-2018-8009
> > > > > > >
> > > > > > > All 2.7.x releases before 2.7.7 have the problem. And for
> 2.6.x,
> > the
> > > > > > hadoop
> > > > > > > team seems to drop the support as there is no release about two
> > years, so
> > > > > > > either we keep the original support versions, or we just drop
> > the support
> > > > > > > for the 2.6.x release line.
> > > > > > >
> > > > > > > Zach York  于2018年10月23日周二
> > 上午8:51写道：
> > > > > > >
> > > > > > > > What is the main reason for the change? Build time speedup?
> > > > > > > >
> > > > > > > > Any reason for testing all of the 2.6.x line, but not the
> > 2.7.x line?
> > > > > > We
> > > > > > > > don't check at all for 2.8.x?
> > > > > > > >
> > > > > > > > Can we be more consistent with how we test compatibility? (Do
> > we only
> > > > > > > care
> > > > > > > > about the latest patch release in a line?)
> > > > > > > >
> > > > > > > > Sorry If I'm missing some of the reasoning, but at a surface
> > level it
> > > > > > > seems
> > > > > > > > fairly arbitrary which releases we are cutting.
> > > > > > > >
> > > > > > > > On Mon, Oct 22, 2018 at 5:44 PM Sean Busbey <
> bus...@apache.org>
> > wrote:
> > > 

Re: [DISCUSS] Gathering metrics on HBase versions in use

[Peter Somogyi]

I like the idea to have some sort of metrics from the users.

I agree with Allan that in many cases HBase cluster is in an internal
network making the data collection difficult or not even possible. It could
lead us to an incorrect view if these generally bigger clusters do not
appear in the metrics but is full with stats from standalone test
environments that were just started once and never again.

Collecting download information could give us a better picture but in this
statistics the latest version might be overrepresented and we won't know
which releases are currently used in the field.

What do you think about collecting page views of Reference guide tied to
specific releases? Someone searching in 1.4 Ref guide probably using HBase
1.4 or in the process of setting it up.

Thanks,
Peter

On Thu, Nov 15, 2018 at 4:56 AM 张铎(Duo Zhang)  wrote:

> +1 on collecting the download information.
>
> And collecting data when starting up is a bit dangerous I'd say, both
> technically and legally...
>
> Maybe a possible way is to add a link on the master state page,  or some
> ASCII arts in the master start log, to guide the people to our survey?
>
> Allan Yang  于2018年11月15日周四 上午11:23写道：
>
> > I also think having metrics about the downloads from Apache/archives is a
> > doable action. Most HBase clusters are running in user's Intranet with no
> > public access, sending anonymous data from them may not be possible. And
> > also we need to find a way to obtain their authorization I think...
> > Best Regards
> > Allan Yang
> >
> > Zach York  于2018年11月15日周四 上午5:35写道：
> >
> > > Can we have metrics around the downloads from Apache/archives? I'm not
> > sure
> > > how that is all set up, but might be a low cost way to get some
> metrics.
> > >
> > > On Wed, Nov 14, 2018, 12:12 PM Andrew Purtell  > wrote:
> > >
> > > > While it seems you are proposing some kind of autonomous ongoing
> usage
> > > > metrics collection, please note I ran an anonymous version usage
> survey
> > > via
> > > > surveymonkey for 1.x last year. It was opt in and there were no PII
> > > > concerns by its nature. All of the issues around data collection,
> > > storage,
> > > > and processing were also handled (by surveymonkey). Unfortunately I
> > > > recently cancelled my account.
> > > >
> > > > For occasional surveys something like that might work. Otherwise
> there
> > > are
> > > > a ton of questions: How do we generate the data? How do we get
> per-site
> > > > opt-in permission? How do we collect the data? Store it? Process it?
> > > Audit
> > > > it? Seems more trouble than it's worth and requires ongoing volunteer
> > > > hosting and effort to maintain.
> > > >
> > > >
> > > > On Wed, Nov 14, 2018 at 11:47 AM Misty Linville 
> > > wrote:
> > > >
> > > > > When discussing the 2.0.x branch in another thread, it came up that
> > we
> > > > > don’t have a good way to understand the version skew of HBase
> across
> > > the
> > > > > user base. Metrics gathering can be tricky. You don’t want to
> capture
> > > > > personally identifiable information (PII) and you need to be
> > > transparent
> > > > > about what you gather, for what purpose, how long the data will be
> > > > > retained, etc. The data can also be sensitive, for instance if a
> > large
> > > > > number of installations are running a version with a CVE or known
> > > > > vulnerability against it. If you gather metrics, it really needs to
> > be
> > > > > opt-out rather than opt-in so that you actually get a reasonable
> > amount
> > > > of
> > > > > data. You also need to stand up some kind of metrics-gathering
> > service
> > > > and
> > > > > run it somewhere, and some kind of reporting / visualization
> tooling.
> > > The
> > > > > flip side of all these difficulties is a more intelligent way to
> > decide
> > > > > when to retire a branch or when to communicate more broadly /
> loudly
> > > > asking
> > > > > people in a certain version stream to upgrade, as well as where to
> > > > > concentrate our efforts.
> > > > >
> > > > > I’m not sticking my hand up to implement such a monster. I only
> > wanted
> > > to
> > > > > open a discussion and see what y’all think. It seems to me that a
> few
> > > > > must-haves are:
> > > > >
> > > > > - Transparency: Release notes, logging about the status of
> > > > > metrics-gathering (on or off) at master or RS start-up, logging
> about
> > > > > exactly when and what metrics are sent
> > > > > - Low frequency: Would we really need to wake up and send metrics
> > more
> > > > > often than weekly?
> > > > > - Conservative approach: Only collect what we can find useful
> today,
> > > > don’t
> > > > > collect the world.
> > > > > - Minimize PII: This probably means not trying to group together
> > > > > time-series results for a given server or cluster at all, but could
> > > make
> > > > > the data look like there were a lot more clusters running in the
> > world
> > > > than
> > > > > really are.
> > > > > - Who has access to the data? 

Access to ASF Jenkins

[Peter Somogyi]

Hi,

I'd be interested to work on precommit integration for hbase-connectors
repository. (HBASE-21432)
Can I request access to make modifications to Apache Jenkins in order to
create new job for this integration?

Thanks,
Peter

Re: [ANNOUNCE] New HBase committer Jingyun Tian

[Peter Somogyi]

Congratulations Jingyun!

On Tue, Nov 13, 2018 at 8:54 AM 张铎(Duo Zhang)  wrote:

> On behalf of the Apache HBase PMC, I am pleased to announce that Jingyun
> Tian has accepted the PMC's invitation to become a committer on the
> project. We appreciate all of Jingyun's generous contributions thus far and
> look forward to his continued involvement.
>
> Congratulations and welcome, Jingyun!
>

Re: [VOTE] The first HBase 1.4.8 release candidate (RC0) is available

[Peter Somogyi]

+1 (non-binding)

Signature, checksum: OK
Apache Rat check: OK
Unit tests (Maven 3.5.3, Oracle Java 1.8.0_181): OK
CHANGES.txt, README.txt, LICENSE.txt, NOTICE.txt: OK
LTT 1M rows: OK
Web UI: OK
Shell basic functionalities: OK
Start in pseudo distributed mode (Hadoop 2.7.4)

Thanks,
Peter

On Tue, Oct 2, 2018 at 5:58 PM Andrew Purtell  wrote:

> The first HBase 1.4.8 release candidate (RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.8RC0/ and Maven
> artifacts are available in the temporary repository
> https://repository.apache.org/content/repositories/orgapachehbase-1233/
>
> The git tag corresponding to the candidate is '1.4.8RC0' (91118ce5f1).
>
> A detailed source and binary compatibility report for this release is
> available for your review at
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.8RC0/compat-check-report.html
> . There are no reported compatibility issues.
>
> A list of the 33 issues resolved in this release can be found at
> https://s.apache.org/xpxo .
>
> Please try out the candidate and vote +1/0/-1.
>
> The vote will be open for at least 72 hours. Unless objection I will try to
> close it Monday October 8, 2018 if we have sufficient votes.
>
> Prior to making this announcement I made the following preflight checks:
>
> RAT check passes (7u80)
> Unit test suite passes (7u80, 8u181)
> Opened the UI in a browser, poked around
> LTT load 1M rows with 100% verification and 20% updates (8u181)
> ITBLL 500M rows with serverKilling monkey (8u181)
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Change in excluded list for PreCommit job

[Peter Somogyi]

Hi,

>From now on the PreCommit-HBASE-Build job on builds.apache.org uses the
flaky list for the target branch.
You can still set the EXCLUDE_TESTS_URL parameter to specify different
exclude list (e.g. rely on master exclude list for a branch-2.0 patch) but
for that you need to manually trigger a job.

If you find any issues with the PreCommit run ping me on HBASE-21547 or
reply to this email.

Thanks,
Peter

Re: Requesting access to hbase slack channel

[Peter Somogyi]

Invite sent.

On Wed, Jan 16, 2019 at 1:03 PM Nihal Jain  wrote:

> Hi
>
> Could you please invite me: nihaljain...@gmail.com  >?
>
> Regards,
> Nihal
>
> On Wed, 16 Jan, 2019, 2:54 PM Peter Somogyi 
> > Sent invitation to madhurpan...@gmail.com.
> >
> > On Wed, Jan 16, 2019 at 7:27 AM Madhur Pant 
> > wrote:
> >
> > > Hi Team,
> > >
> > > I was wondering if I could get access to the HBase user slack channel
> > >
> > > https://apache-hbase.slack.com
> > >
> > > It says here <https://issues.apache.org/jira/browse/HBASE-16413>
> that I
> > > should email you guys  :)
> > >
> > > Thanks,
> > > Madhur Pant
> > >
> >
>

Re: Requesting access to hbase slack channel

[Peter Somogyi]

Sent.

On Fri, Jan 18, 2019 at 7:48 AM Abhishek Gupta  wrote:

> Hi,
>
> I would like an invitation too abhila...@gmail.com
>
> Thanks
>
> On Fri, Jan 18, 2019 at 11:38 AM Manjeet Singh  >
> wrote:
>
> > Done
> >
> > On Fri, 18 Jan 2019, 11:24 Buchi Reddy Busi Reddy  > wrote:
> >
> > > Can you also invite mailtobu...@gmail.com please?
> > >
> > > On Thu, Jan 17, 2019 at 8:34 PM Manjeet Singh <
> > manjeet.chand...@gmail.com>
> > > wrote:
> > >
> > > > Seems someone else already did it
> > > >
> > > > Manjeet
> > > >
> > > > On Wed, 16 Jan 2019, 17:33 Nihal Jain  > > >
> > > > > Hi
> > > > >
> > > > > Could you please invite me: nihaljain...@gmail.com <
> > > > nihaljain...@gmail.com
> > > > > >?
> > > > >
> > > > > Regards,
> > > > > Nihal
> > > > >
> > > > > On Wed, 16 Jan, 2019, 2:54 PM Peter Somogyi  > > wrote:
> > > > >
> > > > > > Sent invitation to madhurpan...@gmail.com.
> > > > > >
> > > > > > On Wed, Jan 16, 2019 at 7:27 AM Madhur Pant <
> > madhurpan...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Team,
> > > > > > >
> > > > > > > I was wondering if I could get access to the HBase user slack
> > > channel
> > > > > > >
> > > > > > > https://apache-hbase.slack.com
> > > > > > >
> > > > > > > It says here <
> https://issues.apache.org/jira/browse/HBASE-16413>
> > > > > that I
> > > > > > > should email you guys  :)
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Madhur Pant
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] First release candidate for HBase 1.2.10 is available

[Peter Somogyi]

Stack, looks like you were checking the sha sum for the
hbase-1.2.10-src.tar.gz.sha512 and not the tar.gz.

On Mon, Jan 14, 2019 at 7:07 PM Stack  wrote:

> +1
>
> Sig good.
>
> Having trouble w/ sha512:
>
> $ more hbase-1.2.10-src.tar.gz.sha512
> hbase-1.2.10-src.tar.gz: D800AEEC 1F6B448D 33C15C5A EA5ECE2E 965C82F1
> C68DA586
>  BA6DB8A7 471573A7 09434016 2E5A14C0 87EF188A
> 365A4009
>  3F726587 21F85D4A 57DA50F1 E940EEE6
> kalashnikov:Downloads stack$ openssl dgst -sha512
> ./hbase-1.2.10-src.tar.gz.sha512
> SHA512(./hbase-1.2.10-src.tar.gz.sha512)=
>
> 87a16e7dc1f65c7d23517eedeb6e2b5c5d3b80443f432066d545e0026d0048c49b9f0ce61cd8e42a3e514740b3a09369523e08511cca31dee343c2d32784d875
>
> They don't match for me.
>
> Had to use 3.5 instead of 3.6 to build.
>
> Built it. Started it. Loaded data. Confirmed it made it in. Looked at logs
> and UI.
>
> S
>
> On Mon, Jan 7, 2019 at 5:51 PM Sean Busbey  wrote:
>
> > The first release candidate for HBase 1.2.10 is available for download:
> >
> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.10RC0/
> >
> > Maven artifacts are also available in a staging repository at:
> >
> > https://repository.apache.org/content/repositories/orgapachehbase-1249/
> >
> > Artifacts are signed with my key (0D80DB7C) published in our KEYS
> > file at http://www.apache.org/dist/hbase/KEYS
> >
> > The RC corresponds to the signed tag 1.2.10RC0, which currently points
> > to commit ref
> >
> > 18f428abb64b405de24d164425e470512e82f287
> >
> > HBase 1.2.10 is the tenth maintenance release in the HBase 1.2 line,
> > continuing on the theme of bringing a stable, reliable database to
> > the Hadoop and NoSQL communities. This release includes about a half
> > dozen bug fixes done in the month since 1.2.9.
> >
> > The detailed source and binary compatibility report vs 1.2.9 has been
> > published for your review, at:
> >
> > https://s.apache.org/hbase-1.2.10-rc0-compat-report
> >
> > The report shows some issues with two IA.LimitedPrivate classes annotated
> > for use in TOOLS and CONFIG, as well as a false positive incompatibility
> > for
> > the WALCellCodec class.
> >
> > Critical fixes include:
> >
> > * HBASE-21387 - Race condition surrounding in progress snapshot handling
> in
> > snapshot cache leads to loss of snapshot files
> > * HBASE-21492 - CellCodec Written To WAL Before It's Verified
> > * HBASE-21504 - If enable FIFOCompactionPolicy, a compaction may write a
> > "empty" hfile whose maxTimeStamp is long max. This kind
> of
> > hfile will never be archived.
> > * HBASE-21582 - If call HBaseAdmin#snapshotAsync but forget call
> > isSnapshotFinished, then SnapshotHFileCleaner will skip
> to
> > run every time
> >
> > The full list of fixes included in this release is available at:
> >
> > https://s.apache.org/hbase-1.2.10-jira-release-notes
> >
> > and in the CHANGES.txt file included in the distribution.
> >
> > Please try out this candidate and vote +1/-1 on whether we should
> > release these artifacts as HBase 1.2.10.
> >
> > The VOTE will remain open for at least 72 hours. Given sufficient votes
> > I would like to close it on January 11th, 2019.
> >
> > thanks!
> >
> > -busbey
> >
> > as of this email the posted artifacts have the following SHA512:
> >
> > hbase-1.2.10-src.tar.gz:
> > D800AEEC 1F6B448D 33C15C5A EA5ECE2E 965C82F1 C68DA586
> > BA6DB8A7 471573A7 09434016 2E5A14C0 87EF188A 365A4009
> > 3F726587 21F85D4A 57DA50F1 E940EEE6
> >
> > hbase-1.2.10-bin.tar.gz:
> > BA085D9E 0EBC67FC E37A4F47 02C98EB0 2EFEF8BE 81AE4388
> > 16A0CC4A 6614788A 4CBF0ABE 47F02C85 ECF4C20E 89343417
> > F2A80FD8 B80481D0 DD2B844B 580D143F
> >
> >
>

Re: Requesting access to hbase slack channel

[Peter Somogyi]

Sent invitation to madhurpan...@gmail.com.

On Wed, Jan 16, 2019 at 7:27 AM Madhur Pant  wrote:

> Hi Team,
>
> I was wondering if I could get access to the HBase user slack channel
>
> https://apache-hbase.slack.com
>
> It says here   that I
> should email you guys  :)
>
> Thanks,
> Madhur Pant
>

Re: [ANNOUNCE] Please welcome Peter Somogyi to the HBase PMC

[Peter Somogyi]

Thank you everyone! It is a great honor for me!
Peter

On Tue, Jan 22, 2019 at 2:36 AM Duo Zhang  wrote:

> On behalf of the Apache HBase PMC I am pleased to announce that Peter
> Somogyi
> has accepted our invitation to become a PMC member on the Apache HBase
> project.
> We appreciate Peter stepping up to take more responsibility in the HBase
> project.
>
> Please join me in welcoming Peter to the HBase PMC!
>

Re: [VOTE] The first HBase 1.3.3 release candidate (RC0) is available

[Peter Somogyi]

+1 (non-binding)

Checksum, signature: OK
Build from source: OK
Rat check: OK
Unit tests: OK
TestReplicationSmallTests and TestRemoveRegionMetrics failed once but I
was not able to reproduce
Shell commands: OK
Web UI: OK

Peter

On Wed, Dec 19, 2018 at 9:42 AM Francis Christopher Liu <
toffer@gmail.com> wrote:

> +1 (Binding)
>
> I checked the following:
> 1. Checksums and signatures
> 2. Rat
> 3. Built From Source and Ran unit tests
> 4. Some shell commands
> 5. Web UI
> 6. LTT with 1M rows
>
> Thanks,
> Francis
>
> On Fri, Dec 14, 2018 at 10:43 PM Sakthi 
> wrote:
>
> > (+1 Non-Binding)
> >
> >1. Checksums and signatures(both src and bin): OK
> >2. Rat Check: OK
> >3. Built from source: OK
> >4. Unit Tests: OK
> >5. Basic Shell commands: OK
> >6. Web UI: OK
> >7. LTT with 1M rows: OK
> >
> > Sakthi
> >
> > On Fri, Dec 14, 2018 at 6:18 PM Andrew Purtell 
> > wrote:
> >
> > > The first HBase 1.3.3 release candidate (RC0) is available for download
> > at
> > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.3RC0/ and Maven
> > > artifacts are available in the temporary repository
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1244/
> > >
> > > The git tag corresponding to the candidate is '1.3.3RC0' (a75a458e0c).
> > >
> > > A detailed source and binary compatibility report for this release is
> > > available at
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.3RC0/compat-check-report.html
> > > . I believe there are no reported compatibility issues that are out of
> > > policy, justifiable, or have not been previously discussed, like the
> > > removal of Base64. Please review and raise any concerns if you have
> them.
> > >
> > > A list of the 174 issues resolved in this release can be found at
> > > https://s.apache.org/uKCX .
> > >
> > > Please try out the candidate and vote +1/0/-1.
> > >
> > > The vote will be open for at least 72 hours. Unless objection I will
> try
> > to
> > > close it Friday December 21, 2018 if we have sufficient votes.
> > >
> > > Prior to making this announcement I made the following preflight
> checks:
> > >
> > > RAT check passes (7u80)
> > > Unit test suite passes (8u172)
> > > Loaded the UI in a browser, poked around (8u181)
> > > LTT load 100M rows with 100% verification and 20% updates (8u181)
> > > ITBLL 500M rows with slowDeterministic monkey (8u181)
> > > ITBLL 500M rows with serverKilling monkey (8u181)
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >- A23, Crosstalk
> > >
> >
>

Re: [VOTE] The second HBase 1.4.9 release candidate (RC1) is available

[Peter Somogyi]

+1 (non-binding)

* Signature, checksum: OK
* Apache Rat check: OK
* Build from source: OK
* CHANGES.txt: OK
* Unit tests (8u191, Maven 3.5.3): OK
* LTT 1M rows: OK
* Shell commands: OK
* Web UI: OK

On Sat, Dec 8, 2018 at 7:01 AM Andrew Purtell 
wrote:

> YCSB workloads are not that interesting. I think it’s still useful as a
> “standard” tool though that indicates we aren’t doing worse. Also, there
> may be more difference under overload conditions. Next time.
>
> Using Phoenix and some of our internal test tools we can generate
> workloads that turn up interesting differences at the day job, but mostly
> between 0.98 and any 1.x, and the changes were small and additive over
> time. Some of our folks contributed perf fixes that return some of the
> difference, 10%, 20% here and there. There are opportunities for more.
>
> For 1.5 branch-1 has some interesting changes, like pressure aware
> compaction rate limiting on by default, which may change things (via
> influence on GC). TinyLRU if it goes in might also be interesting.
>
>
> > On Dec 7, 2018, at 8:02 PM, Stack  wrote:
> >
> > Thanks for the test runs.
> >
> > The diffs are miniscule. After so many releases, would have expected a
> > tendency up or down but not constant (smile).
> >
> > S
> >
> >> On Fri, Dec 7, 2018 at 5:34 PM Andrew Purtell 
> wrote:
> >>
> >> Today I did a comparison between 1.2.6.1 and 1.4.9RC1 with YCSB. The
> >> results are close. Overall runtimes are almost the same. In the average
> and
> >> high percentile measures there is a general upward trend but nothing
> that
> >> looks like a significant regression. Still for 1.5.0 I think we should
> see
> >> if it's possible to lower measures made by YCSB closer to those observed
> >> with 1.2.
> >>
> >> Linux version 4.14.55-62.37.amzn1.x86_64
> >> c3.8xlarge x 5
> >> OpenJDK Runtime Environment (build 1.8.0_181-shenandoah-b13)
> >> -Xms20g -Xmx20g -XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+UseNUMA
> >> -XX:-UseBiasedLocking -XX:+ParallelRefProcEnabled
> >> Hadoop 2.8.5
> >> Init: Load 100 M rows and snapshot
> >> Run: Delete table, clone and redeploy from snapshot, run 10 M operations
> >> (except 1M for workload E)
> >> Args: -threads 100 -target 5 (except 1 for workload E)
> >>
> >> YCSB Workload A
> >>
> >> target 50k/op/s 1.2.6.1 1.4.9
> >>
> >>
> >>
> >> [OVERALL], RunTime(ms) 200581 200605
> >> [OVERALL], Throughput(ops/sec) 49855 49849
> >> [READ], AverageLatency(us) 491 517
> >> [READ], MinLatency(us) 233 273
> >> [READ], MaxLatency(us) 140287 165503
> >> [READ], 95thPercentileLatency(us) 605 647
> >> [READ], 99thPercentileLatency(us), 880 1031
> >> [UPDATE], AverageLatency(us) 1332 1327
> >> [UPDATE], MinLatency(us) 711 692
> >> [UPDATE], MaxLatency(us) 137215 160383
> >> [UPDATE], 95thPercentileLatency(us) 1790 1800
> >> [UPDATE], 99thPercentileLatency(us) 2333 2495
> >>
> >> YCSB Workload B
> >>
> >> target 50k/op/s 1.2.6.1 1.4.9
> >>
> >>
> >>
> >> [OVERALL], RunTime(ms) 200569 200566
> >> [OVERALL], Throughput(ops/sec) 49858 49859
> >> [READ], AverageLatency(us),  438 445
> >> [READ], MinLatency(us) 198 216
> >> [READ], MaxLatency(us) 143615 153343
> >> [READ], 95thPercentileLatency(us) 539 552
> >> [READ], 99thPercentileLatency(us) 806 957
> >> [UPDATE], AverageLatency(us) 1098 1064
> >> [UPDATE], MinLatency(us) 746 762
> >> [UPDATE], MaxLatency(us) 141183 149503
> >> [UPDATE], 95thPercentileLatency(us) 1334 1336
> >> [UPDATE], 99thPercentileLatency(us) 1695 1777
> >>
> >> YCSB Workload C
> >>
> >> target 50k/op/s 1.2.6.1 1.4.9
> >>
> >>
> >>
> >> [OVERALL], RunTime(ms) 200543 200559
> >> [OVERALL], Throughput(ops/sec) 49865 49861
> >> [READ], AverageLatency(us) 348 340
> >> [READ], MinLatency(us) 174 182
> >> [READ], MaxLatency(us) 140287 161279
> >> [READ], 95thPercentileLatency(us) 428 421
> >> [READ], 99thPercentileLatency(us) 793 841
> >>
> >> YCSB Workload D
> >>
> >> target 50k/op/s 1.2.6.1 1.4.9
> >>
> >>
> >>
> >> [OVERALL], RunTime(ms) 200557 200577
> >> [OVERALL], Throughput(ops/sec) 49861 49856
> >> [READ], AverageLatency(us) 528 503
> >> [READ], MinLatency(us) 187 213
> >> [READ], MaxLatency(us) 134655 147199
> >> [READ], 95thPercentileLatency(us) 1395 991
> >> [READ], 99thPercentileLatency(us) 1880 1721
> >> [INSERT], AverageLatency(us) 1272 1245
> >> [INSERT], MinLatency(us) 830 827
> >> [INSERT], MaxLatency(us) 124479 140671
> >> [INSERT], 95thPercentileLatency(us) 1518 1505
> >> [INSERT], 99thPercentileLatency(us) 2249 2553
> >>
> >> YCSB Workload E
> >>
> >> target 10k/op/s 1.2.6.1 1.4.9
> >>
> >>
> >>
> >> [OVERALL], RunTime(ms) 100564 100584
> >> [OVERALL], Throughput(ops/sec) 9944 9942
> >> [SCAN], AverageLatency(us) 4297 3700
> >> [SCAN], MinLatency(us) 765 740
> >> [SCAN], MaxLatency(us) 1229823 1056767
> >> [SCAN], 95thPercentileLatency(us) 10503 9855
> >> [SCAN], 99thPercentileLatency(us) 22655 19007
> >> [INSERT], AverageLatency(us) 3178 2707
> >> [INSERT], MinLatency(us) 935 885
> >> [INSERT], MaxLatency(us) 1020415 148479
> >> 

Re: [VOTE] First release candidate for HBase 2.0.3 is available

[Peter Somogyi]

+1 (non-binding)

First of all, the test failure with TestMasterFailoverWithProcedures is
only test related so you should not sink this RC!

Checksum, signature: OK
Build from source: OK
Rat check: OK
LTT 1M rows: OK
Shell basic functionalities: OK
Unit tests: Partially OK (Some flaky tests that were discussed before)

Thanks,
Peter

On Thu, Nov 29, 2018 at 8:10 PM Azhaku Sakthi Vel Muthu Krishnan
 wrote:

> (+1 Non Binding)
>
>1. Checksums and signatures(both src and bin): OK
>2. Rat Check: OK
>3. Built from source: OK
>4. Basic Shell commands: OK
>5. Web UI: OK
>6. LTT with 1M rows: OK
>7. Unit Tests run failed mid way, need to re-trigger. But encountered
>TestFifoRpcScheduler failure so far:
>   - [ERROR]
>   testCallQueueInfo(org.apache.hadoop.hbase.ipc.TestFifoRpcScheduler)
> Time
>   elapsed: 7.404 s <<< FAILURE!
>   - java.lang.AssertionError: expected:<10> but was:<9>
>   - at
>
> org.apache.hadoop.hbase.ipc.TestFifoRpcScheduler.testCallQueueInfo(TestFifoRpcScheduler.java:137)
>
> Sakthi
>
> On Thu, Nov 29, 2018 at 8:08 AM Sean Busbey  wrote:
>
> > On Thu, Nov 29, 2018 at 10:06 AM Allan Yang  wrote:
> > >
> > > I think we can release 2.0.3 first then fix these flaky tests later. I
> > > glanced at the flaky board for branch-2.1, those tests are still flaky
> in
> > > branch-2.1[1], they are not the fault of 2.0.3. They should not block
> the
> > > release of 2.0.3.
> > >
> >
> > I agree with Allan here. I should be able to finish running through
> > testing the RC this evening.
> >
>

Re: [DISCUSS] move to gitbox

[Peter Somogyi]

How should we verify pull requests in the new workflow? I wouldn't like to
force contributors to create a PR and also attach the same patch file to
Jira to have it tested. In case the plan is to create PR-based precommit
I'd recommend to test run it on hbase-connectors or hbase-operator tools
gitbox repositories.


On Sat, Dec 8, 2018 at 3:30 AM Sean Busbey  wrote:

> Yes I definitely agree. I think that'll take some committer practice
> and I'll want to have a decent section in the ref guide to point folks
> to. On the plus side, there's a step committers have to go through to
> link their ASF ID to their GitHub profile before they can start
> merging through the GitHub UI. So if we tell folks about how to do
> that step at the same time as show them how to make sure they're
> squash merging maybe we'll avoid some mistakes.
> On Fri, Dec 7, 2018 at 8:26 PM Andrew Purtell  wrote:
> >
> > However you want to best phrase it, squash merging for commit is a must,
> I
> > think. Depending on the contributor's style there could be 1 or 10
> commits
> > comprising the PR. Even more than one commit for a change encompassed by
> a
> > JIRA would make cherry picking between the branches unnecessarily
> onerous.
> > This is really the only thing I'd like to establish as very important.
> >
> >
> > On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey  wrote:
> >
> > > The move to gitbox doesn't require us to only accept github PRs. Given
> > > the current rate of contributions via patches on JIRA vs GitHub PRs, I
> > > wouldn't want to push for that now.
> > >
> > > The change does make it easier for us to start encouraging PR
> > > submissions, because committers will be able to directly merge from
> > > the GitHub UI.
> > >
> > > I'd recommend we try to keep this as a small incremental change. That
> > > would mean:
> > >
> > > * committers ensure there's an associated JIRA for release note and
> > > precommit checks (that can be just by pinging the contributor to go
> > > make one)
> > > * backports are still handled by the committer if they're simple and
> > > the contributor if there's a problem. I think saying "open a new PR to
> > > backport to branch FOO" is perfectly reasonable since it's analogous
> > > to when we ask contributors to attach a branch specific patch.
> > > * committers ensure the pushed commit has a message that follows our
> > > current practice (which would mean looking out for the "helpful"
> > > subject wrapping)
> > > * Squash merge is an option when the committer goes to accept the PR.
> > > the contributor is free to either push additional commits or squash on
> > > their branch when working through reviews, I don't think we need to
> > > weigh in on how contributors choose which of those works best for
> > > them.
> > >
> > > That way we can also incrementally improve how well we handle PR
> > > submissions by better documenting expectations and building up
> > > additional tooling (e.g. having our precommit feedback go directly to
> > > the PR instead of being tied to a JIRA)
> > > On Fri, Dec 7, 2018 at 12:09 PM Stack  wrote:
> > > >
> > > > On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey 
> wrote:
> > > >
> > > > > Hi folks!
> > > > >
> > > > > Per the email from infra "[NOTICE] Mandatory relocation of Apache
> git
> > > > > repositories on git-wip-us.apache.org" ( https://s.apache.org/0sfe
> )
> > > it
> > > > > looks like the future of interacting directly with PRs is coming
> sooner
> > > > > rather than later.
> > > > >
> > > > > I think we should move to gitbox ASAP rather than wait for the
> crunch.
> > > If
> > > > > we hit a rough spot we're more likely to get some help when things
> > > aren't
> > > > > busy. Maybe we wait until our open RCs close so that folks that
> need
> > > to tag
> > > > > those releases don't need to update their workflow first?
> > > > >
> > > > > Presuming everyone still agrees that we get value out of JIRA, I
> think
> > > we
> > > > > need update our committer guidelines to expressly remind folks to
> > > check on
> > > > > things like commit messages before merging PRs, as well as to
> ensure
> > > folks
> > > > > use the "squash and merge" option to keep the git history less
> > > complicated.
> > > > > Probably a good time to add text about the importance of
> backporting,
> > > since
> > > > > there isn't a github UI for doing that.
> > > > >
> > > >
> > > >
> > > > Sounds good.
> > > >
> > > > Use this thread to list what needs documentation? (Agree with the
> "Need
> > > to
> > > > sort all of this out and provide clarity now before a switch over."
> from
> > > > Andrew).
> > > >
> > > > What should the commit be like? Should be like now? What about that
> ugly
> > > > bleed that happens when the first line is too long and gets dumped
> into
> > > the
> > > > textbox below ... which then becomes the log IIRC.
> > > >
> > > > When do we do the squash merge? Is that the committer who does this
> after
> > > > rounds of review?
> > > >
> > > > I like 

Re: [ANNOUNCE] Allan Yang joins the Apache HBase PMC

[Peter Somogyi]

Congratulations!

On Thu, Nov 29, 2018 at 12:32 PM Chunhui Shen  wrote:

> Congratulations, Allan !
> At 2018-11-29 00:11:08, "Yu Li"  wrote:
> >On behalf of the Apache HBase PMC I am pleased to announce that Allan Yang
> >has accepted our invitation to become a PMC member on the Apache HBase
> >project. We appreciate Allan stepping up to take more responsibility in
> the
> >HBase project.
> >
> >Please join me in welcoming Allan to the HBase PMC!
> >
> >Best Regards,
> >Yu
>

Re: Failure: hbase.apache.org HTML Checker

[Peter Somogyi]

This issue is with the content of index.html file. check-website-links.sh
script checks for ERROR in the generated index.html and at this time the
content of this html is empty.
I think this is the root cause:

Checking /0.94/apidocs/src-html/org/apache/hadoop/hbase/thrift/generate ...
Warning: hbase.apache.org 95.216.24.32
Error: timed out reading data
checking server 40.79.78.1

Processing ...

writing files to link_report
wrote 24 txt files
wrote 22 html files
wrote index file index.html

The final if statement in check-website-links.sh is incorrect. Actually it
should have passed at this time and failed on previous executions.

On Sat, Dec 8, 2018 at 3:35 PM Sean Busbey  wrote:

> Hurm. No obvious why this failed. It reports a ton of bad links, but all of
> the successful runs before also report a ton of them if you look at the
> console output.
>
> On Fri, Dec 7, 2018, 23:25 Apache Jenkins Server <
> jenk...@builds.apache.org
> wrote:
>
> > Failure
> >
> > Either the Jenkins job failed, or (more likely) HTML errors were found.
> >
> > Unless the Jenkins job itself failed, the HTML and link-checking report
> > for http://hbase.apache.org is available at
> >
> https://builds.apache.org/job/HBase%20Website%20Link%20Checker/179/artifact/link_report/index.html
> > .
> >
> > Otherwise, see
> >
> https://builds.apache.org/job/HBase%20Website%20Link%20Checker/179/console
> > .
>

Re: [VOTE] First release candidate for HBase 2.0.3 is available

[Peter Somogyi]

I'm also facing test issues. TestMasterFailoverWithProcedures is failing
frequently on my machine and can be found on the flaky dashboard for
multiple branches.  Created HBASE-21518 issue for this.

On Tue, Nov 27, 2018 at 2:28 PM 张铎(Duo Zhang)  wrote:

> I'm still testing but it is really hard for me to get all UTs pass, but not
> the same UT... Still trying...
>
> Artem Ervits  于2018年11月27日周二 上午6:03写道：
>
> > +1 (non-binding)
> >
> >   signatures and sums for src and bin: OK
> >   installed on pseudodistributed hadoop 2.7.7: OK
> >   hbase shell: OK
> >   logs: OK
> >   UI: OK
> >   LTT 1M write/read 20%: OK
> >   compile from src OpenJDK 1.8.0_191: OK
> >   Java: write 1M: OK
> >
> > On Sun, Nov 25, 2018 at 7:29 PM Stack  wrote:
> >
> > > The first release candidate for HBase 2.0.3 is available for download:
> > >
> > >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.3RC0/
> > >
> > > Maven artifacts are also available in a staging repository at:
> > >
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1237
> > >
> > > Artifacts are signed with my key (DB9D313DA7874F29) published in our
> > > KEYS file at http://www.apache.org/dist/hbase/KEYS
> > >
> > > The RC corresponds to the signed tag 2.0.3RC0, which currently points
> > > to commit
> > >
> > >   87a3aea8ee2d284807f7d4fbdac1f6d9dfedbc17
> > >
> > > HBase 2.0.3 is the third maintenance release in the HBase 2.0 line,
> > > continuing on the theme of bringing a stable, reliable database to
> > > the Hadoop and NoSQL communities. This release includes ~120 bug
> > > and improvements fixes done since the 2.0.2 release almost 3 months
> > > ago.
> > >
> > > The detailed source and binary compatibility report vs 2.0.2 has been
> > > published for your review, at:
> > >
> > >
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.3RC0/compat-check-report-2.0.2-vs-2.0.3.html
> > >
> > > The report shows no incompatibilities.
> > >
> > > The full list of fixes included in this release is available in
> > > the CHANGES.md that ships as part of the release also available
> > > here:
> > >
> > >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.3RC0/CHANGES.md
> > >
> > > The RELEASENOTES.md are here:
> > >
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.3RC0/RELEASENOTES.md
> > >
> > > Please try out this candidate and vote +1/-1 on whether we should
> > > release these artifacts as HBase 2.0.3.
> > >
> > > The VOTE will remain open for at least 72 hours. Given sufficient votes
> > > I would like to close it on Thursday, November 29th, 2018.
> > >
> > > Thanks,
> > > S
> > >
> >
>

Re: [VOTE] First release candidate for HBase 2.0.3 is available

[Peter Somogyi]

On my MacBook Pro this test failed 8 out of 20 runs. I made some analysis
over HBASE-21518 and for me it looks like shutdown race condition.

On Tue, Nov 27, 2018 at 6:04 PM Stack  wrote:

> Thanks boys.
>
> I was going off the nightly [1] and the flakey list [2]. They didn't look
> too bad. Shout which tests are causing you issue and I can take a look.
> TestMasterFailoverWithProcedures seems like it fails on occasion, but only
> on the gce runs at < 20% of time. You see different Peter?
>
> Thanks,
> St.Ack
>
> 1. https://bu
> ilds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-2.0/
> 2.
>
> https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests/job/branch-2.0/lastSuccessfulBuild/artifact/dashboard.html
>
> On Tue, Nov 27, 2018 at 7:49 AM Peter Somogyi  wrote:
>
> > I'm also facing test issues. TestMasterFailoverWithProcedures is failing
> > frequently on my machine and can be found on the flaky dashboard for
> > multiple branches.  Created HBASE-21518 issue for this.
> >
> > On Tue, Nov 27, 2018 at 2:28 PM 张铎(Duo Zhang) 
> > wrote:
> >
> > > I'm still testing but it is really hard for me to get all UTs pass, but
> > not
> > > the same UT... Still trying...
> > >
> > > Artem Ervits  于2018年11月27日周二 上午6:03写道：
> > >
> > > > +1 (non-binding)
> > > >
> > > >   signatures and sums for src and bin: OK
> > > >   installed on pseudodistributed hadoop 2.7.7: OK
> > > >   hbase shell: OK
> > > >   logs: OK
> > > >   UI: OK
> > > >   LTT 1M write/read 20%: OK
> > > >   compile from src OpenJDK 1.8.0_191: OK
> > > >   Java: write 1M: OK
> > > >
> > > > On Sun, Nov 25, 2018 at 7:29 PM Stack  wrote:
> > > >
> > > > > The first release candidate for HBase 2.0.3 is available for
> > download:
> > > > >
> > > > >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.3RC0/
> > > > >
> > > > > Maven artifacts are also available in a staging repository at:
> > > > >
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachehbase-1237
> > > > >
> > > > > Artifacts are signed with my key (DB9D313DA7874F29) published in
> our
> > > > > KEYS file at http://www.apache.org/dist/hbase/KEYS
> > > > >
> > > > > The RC corresponds to the signed tag 2.0.3RC0, which currently
> points
> > > > > to commit
> > > > >
> > > > >   87a3aea8ee2d284807f7d4fbdac1f6d9dfedbc17
> > > > >
> > > > > HBase 2.0.3 is the third maintenance release in the HBase 2.0 line,
> > > > > continuing on the theme of bringing a stable, reliable database to
> > > > > the Hadoop and NoSQL communities. This release includes ~120 bug
> > > > > and improvements fixes done since the 2.0.2 release almost 3 months
> > > > > ago.
> > > > >
> > > > > The detailed source and binary compatibility report vs 2.0.2 has
> been
> > > > > published for your review, at:
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.3RC0/compat-check-report-2.0.2-vs-2.0.3.html
> > > > >
> > > > > The report shows no incompatibilities.
> > > > >
> > > > > The full list of fixes included in this release is available in
> > > > > the CHANGES.md that ships as part of the release also available
> > > > > here:
> > > > >
> > > > >
> > > https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.3RC0/CHANGES.md
> > > > >
> > > > > The RELEASENOTES.md are here:
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.3RC0/RELEASENOTES.md
> > > > >
> > > > > Please try out this candidate and vote +1/-1 on whether we should
> > > > > release these artifacts as HBase 2.0.3.
> > > > >
> > > > > The VOTE will remain open for at least 72 hours. Given sufficient
> > votes
> > > > > I would like to close it on Thursday, November 29th, 2018.
> > > > >
> > > > > Thanks,
> > > > > S
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] First release candidate for HBase 1.2.9 is available

[Peter Somogyi]

+1 (non-binding)

Verified checksums and signatures
Built from source (Java 8u191, Maven 3.5.3)
Ran unit tests (TestHRegion, TestCellCounter and TestServerCustomProtocol
crashed during execution but reruns succeeded. Probably issue with my env?)
Apache Rat check succeeded
Started binary in pseudo distributed mode (Hadoop 2.7.4)
Ran LTT with 1M rows
Checked basic functionalities of Shell and UI
Skimmed through log files
CHANGES.txt does not have release date for 1.2.9. Will it be added on
actual release time?

Thanks for the release,
Peter

On Sun, Nov 18, 2018 at 7:09 AM Sean Busbey  wrote:

> The first release candidate for HBase 1.2.9 is available for download:
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.9RC0/
>
> Maven artifacts are also available in a staging repository at:
>
> https://repository.apache.org/content/repositories/orgapachehbase-1236/
>
> Artifacts are signed with my key (0D80DB7C) published in our KEYS
> file at http://www.apache.org/dist/hbase/KEYS
>
> The RC corresponds to the signed tag 1.2.9RC0, which currently points
>  to commit ref
>
>  fd0d55b1e5ef54eb9bf60cce1f0a8e4c1da073ef
>
>  HBase 1.2.9 is the ninth maintenance release in the HBase 1.2 line,
>  continuing on the theme of bringing a stable, reliable database to
>  the Hadoop and NoSQL communities. This release includes about a half
>  dozen bug fixes done in the month since 1.2.8.
>
>  The detailed source and binary compatibility report vs 1.2.8 has been
>  published for your review, at:
>
>  https://s.apache.org/hbase-1.2.9-rc0-compat-report
>
>  The report shows no incompatibilities.
>
>  Critical fixes include:
>
>  * HBASE-21347 Backport HBASE-21200 "Memstore flush doesn't finish
>because of seekToPreviousRow() in memstore scanner." to
>branch-1
>  * HBASE-21357 RS should abort if OOM in Reader thread
>  * HBASE-20604 ProtobufLogReader#readNext can incorrectly loop to the
>same position in the stream until the the WAL is rolled
>
>  The full list of fixes included in this release is available at:
>
>  https://s.apache.org/hbase-1.2.9-jira-release-notes
>
>  and in the CHANGES.txt file included in the distribution.
>
>  Please try out this candidate and vote +1/-1 on whether we should
>  release these artifacts as HBase 1.2.9.
>
>  The VOTE will remain open for at least 72 hours. Given sufficient votes
>  I would like to close it on November 26th, 2018.
>
>  thanks!
>
>  -busbey
>
>  as of this email the posted artifacts have the following SHA512:
>
>  hbase-1.2.9-src.tar.gz:
>  49498136 FA865B7C E70C0A81 18F6B221 CA3D0266 C26DDDE2
>  513C206C 4D28E228 048171C2 DD608DB2 0DA164BD ADBED4BF
>  80DC40E4 6D93CC11 6C25C617 CA25E5A7
>
>  hbase-1.2.9-bin.tar.gz:
>  4D9E1278 8634E250 841E55CB 8879EAC1 5C9BCF7F 09DE018A
>  AD0CCB0E 118C2D02 BCA5F4F3 EACB9857 D8236E07 6E3CD0A4
>  43B90567 3AB5C83C AD642547 037588BA
>

Re: [DISCUSS] move to gitbox

[Peter Somogyi]

I believe we reached consensus to migrate our remaining repositories to
GitBox before the mandatory migration which will happen on 7th of February.
Apart from 'hbase' we still have 'hbase-site' and 'hbase-thirdparty'
repositories that also require the same migration process.

>From users' point of view they could still use git://
git.apache.org/hbase.git for read only access, only committers need to
change the remote URL to the GitBox one. Jenkins jobs are already using the
GitHub URL for cloning the repository and I created a patch for the
documentation and website changes in HBASE-21685 that we can merge after
the process is competed.

There's still outstanding work to do before we have good guidelines on
accepting pull requests on GitHub, but the GitBox migration doesn't require
our committers to start working with PRs in a different way.

If there is no disagreement I'd kindly ask one of the PMC members to reach
out to INFRA to perform the migration.

Thanks,
Peter

On Sun, Dec 9, 2018 at 12:56 AM Andrew Purtell 
wrote:

> Sounds good to me except squash merge at commit of PR shouldn’t be an
> option it should be required except for good reason (and I don’t know what
> that would be )
>
> > On Dec 8, 2018, at 3:28 PM, Stack  wrote:
> >
> >> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey  wrote:
> >>
> >> The move to gitbox doesn't require us to only accept github PRs. Given
> >> the current rate of contributions via patches on JIRA vs GitHub PRs, I
> >> wouldn't want to push for that now.
> >>
> >> The change does make it easier for us to start encouraging PR
> >> submissions, because committers will be able to directly merge from
> >> the GitHub UI.
> >>
> >> I'd recommend we try to keep this as a small incremental change. That
> >> would mean:
> >>
> >> * committers ensure there's an associated JIRA for release note and
> >> precommit checks (that can be just by pinging the contributor to go
> >> make one)
> >> * backports are still handled by the committer if they're simple and
> >> the contributor if there's a problem. I think saying "open a new PR to
> >> backport to branch FOO" is perfectly reasonable since it's analogous
> >> to when we ask contributors to attach a branch specific patch.
> >> * committers ensure the pushed commit has a message that follows our
> >> current practice (which would mean looking out for the "helpful"
> >> subject wrapping)
> >> * Squash merge is an option when the committer goes to accept the PR.
> >> the contributor is free to either push additional commits or squash on
> >> their branch when working through reviews, I don't think we need to
> >> weigh in on how contributors choose which of those works best for
> >> them.
> >>
> >> That way we can also incrementally improve how well we handle PR
> >> submissions by better documenting expectations and building up
> >> additional tooling (e.g. having our precommit feedback go directly to
> >> the PR instead of being tied to a JIRA)
> >>
> >
> > This seems reasonable to me. Andrew's strawman would be too radical a
> > change.
> > Thanks,
> > S
> >
> >
> >>> On Fri, Dec 7, 2018 at 12:09 PM Stack  wrote:
> >>>
>  On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey  wrote:
> 
>  Hi folks!
> 
>  Per the email from infra "[NOTICE] Mandatory relocation of Apache git
>  repositories on git-wip-us.apache.org" ( https://s.apache.org/0sfe )
> >> it
>  looks like the future of interacting directly with PRs is coming
> sooner
>  rather than later.
> 
>  I think we should move to gitbox ASAP rather than wait for the crunch.
> >> If
>  we hit a rough spot we're more likely to get some help when things
> >> aren't
>  busy. Maybe we wait until our open RCs close so that folks that need
> >> to tag
>  those releases don't need to update their workflow first?
> 
>  Presuming everyone still agrees that we get value out of JIRA, I think
> >> we
>  need update our committer guidelines to expressly remind folks to
> >> check on
>  things like commit messages before merging PRs, as well as to ensure
> >> folks
>  use the "squash and merge" option to keep the git history less
> >> complicated.
>  Probably a good time to add text about the importance of backporting,
> >> since
>  there isn't a github UI for doing that.
> 
> >>>
> >>>
> >>> Sounds good.
> >>>
> >>> Use this thread to list what needs documentation? (Agree with the "Need
> >> to
> >>> sort all of this out and provide clarity now before a switch over."
> from
> >>> Andrew).
> >>>
> >>> What should the commit be like? Should be like now? What about that
> ugly
> >>> bleed that happens when the first line is too long and gets dumped into
> >> the
> >>> textbox below ... which then becomes the log IIRC.
> >>>
> >>> When do we do the squash merge? Is that the committer who does this
> after
> >>> rounds of review?
> >>>
> >>> I like Andrew's list.
> >>>
> >>> On the 'You can't fix a branch-1 issue where the code 

Re: [VOTE] First release candidate for HBase 1.2.10 is available

[Peter Somogyi]

+1 (non-binding)

Signature, checksum: OK
Apache Rat: OK
Build from source: OK
Unit tests: OK
LTT 1M rows: OK
Web UI: OK
Shell: OK

On Wed, Jan 9, 2019 at 6:30 PM Balazs Meszaros
 wrote:

> +1
>
> - Signatures, checksums: OK
> - Built from source (8u112): OK
> - Unit tests: OK
> - LTT with 1M rows: OK
> - Basic shell commands: OK
> - Web UI: OK
>
> I also hit HBASE-21687 with maven 3.6.
>
> On Wed, Jan 9, 2019 at 12:36 AM Andrew Purtell 
> wrote:
>
> > +1 (binding)
> >
> > Checked sums and signatures: ok
> > Built from source*: ok (7u80)
> > RAT check passed: ok (7u80)
> > Unit tests pass: ok (7u80)
> > LTT load 1M rows: ok (8u172)
> >
> > * - HBASE-21687 is needed on top of the RC for the build to complete with
> > Maven 3.6.
> >
> >
> > On Mon, Jan 7, 2019 at 5:51 PM Sean Busbey  wrote:
> >
> > > The first release candidate for HBase 1.2.10 is available for download:
> > >
> > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.10RC0/
> > >
> > > Maven artifacts are also available in a staging repository at:
> > >
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1249/
> > >
> > > Artifacts are signed with my key (0D80DB7C) published in our KEYS
> > > file at http://www.apache.org/dist/hbase/KEYS
> > >
> > > The RC corresponds to the signed tag 1.2.10RC0, which currently points
> > > to commit ref
> > >
> > > 18f428abb64b405de24d164425e470512e82f287
> > >
> > > HBase 1.2.10 is the tenth maintenance release in the HBase 1.2 line,
> > > continuing on the theme of bringing a stable, reliable database to
> > > the Hadoop and NoSQL communities. This release includes about a half
> > > dozen bug fixes done in the month since 1.2.9.
> > >
> > > The detailed source and binary compatibility report vs 1.2.9 has been
> > > published for your review, at:
> > >
> > > https://s.apache.org/hbase-1.2.10-rc0-compat-report
> > >
> > > The report shows some issues with two IA.LimitedPrivate classes
> annotated
> > > for use in TOOLS and CONFIG, as well as a false positive
> incompatibility
> > > for
> > > the WALCellCodec class.
> > >
> > > Critical fixes include:
> > >
> > > * HBASE-21387 - Race condition surrounding in progress snapshot
> handling
> > in
> > > snapshot cache leads to loss of snapshot files
> > > * HBASE-21492 - CellCodec Written To WAL Before It's Verified
> > > * HBASE-21504 - If enable FIFOCompactionPolicy, a compaction may write
> a
> > > "empty" hfile whose maxTimeStamp is long max. This kind
> > of
> > > hfile will never be archived.
> > > * HBASE-21582 - If call HBaseAdmin#snapshotAsync but forget call
> > > isSnapshotFinished, then SnapshotHFileCleaner will skip
> > to
> > > run every time
> > >
> > > The full list of fixes included in this release is available at:
> > >
> > > https://s.apache.org/hbase-1.2.10-jira-release-notes
> > >
> > > and in the CHANGES.txt file included in the distribution.
> > >
> > > Please try out this candidate and vote +1/-1 on whether we should
> > > release these artifacts as HBase 1.2.10.
> > >
> > > The VOTE will remain open for at least 72 hours. Given sufficient votes
> > > I would like to close it on January 11th, 2019.
> > >
> > > thanks!
> > >
> > > -busbey
> > >
> > > as of this email the posted artifacts have the following SHA512:
> > >
> > > hbase-1.2.10-src.tar.gz:
> > > D800AEEC 1F6B448D 33C15C5A EA5ECE2E 965C82F1 C68DA586
> > > BA6DB8A7 471573A7 09434016 2E5A14C0 87EF188A 365A4009
> > > 3F726587 21F85D4A 57DA50F1 E940EEE6
> > >
> > > hbase-1.2.10-bin.tar.gz:
> > > BA085D9E 0EBC67FC E37A4F47 02C98EB0 2EFEF8BE 81AE4388
> > > 16A0CC4A 6614788A 4CBF0ABE 47F02C85 ECF4C20E 89343417
> > > F2A80FD8 B80481D0 DD2B844B 580D143F
> > >
> > >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>

Re: [VOTE] Second release candidate for HBase 2.1.2 is available for download

[Peter Somogyi]

+1 (non-binding)

Checksum, signature: OK
Build from source: OK
Unit tests: OK
LTT 1M rows: OK
Basic shell commands: OK
Apache Rat: OK

Thanks,
Peter

On Mon, Jan 7, 2019 at 9:20 AM Allan Yang  wrote:

> OK, there is a 2.1.2 pending, will test the RC and come back soon.
> Best Regards
> Allan Yang
>
>
> 张铎(Duo Zhang)  于2019年1月7日周一 下午12:12写道：
>
> > +1(binding)
> >
> > Built from src: OK
> > Checked sums & sigs: All matched
> > Run all UTs(jdk8u151): Fine. The same with testing 2.0.4RC1. With
> > -PrunAllTests several UTs failed, and then passed when running
> sequentially
> > Started a 5 nodes cluster: OK, the master UI is fine
> > Run basic shell cmds: OK
> > Run LTT with 1M rows: Read & Write, both OK, and then major compact the
> > table, and execute the count command in shell, also 1M rows returned.
> >
> > Stack  于2019年1月3日周四 上午9:23写道：
> >
> > > The second release candidate for HBase 2.1.2 is available for download:
> > >
> > > * https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC1/
> > > *
> > >
> > > Maven artifacts are also available in a staging repository at:
> > >
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1247
> > >
> > > Artifacts are signed with my key (DB9D313DA7874F29) published in our
> > > KEYS file at http://www.apache.org/dist/hbase/KEYS
> > >
> > > The RC corresponds to the signed tag 2.1.2RC1, which currently points
> > > to commit
> > >
> > >   1dfc418f77801fbfb59a125756891b9100c1fc6d
> > >
> > > HBase 2.1.2 is the third maintenance release in the HBase 2.0 line,
> > > continuing on the theme of bringing a stable, reliable database to
> > > the Hadoop and NoSQL communities. It fixes a critical issue found
> > > in the recent 2.0.3 and 2.1.1 releases (only), HBASE-21551. 2.1.2
> > > includes ~70 bug and improvement fixes done since the 2.1.1,
> > > ~ eight weeks ago.
> > >
> > > The detailed source and binary compatibility report vs 2.1.1 has been
> > > published for your review, at:
> > >
> > >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC1
> > > /compatibility_report_2.1.1vs2.1.2.html
> > >
> > > The report shows no incompatibilities.
> > >
> > > The full list of fixes included in this release is available in
> > > the CHANGES.md that ships as part of the release also available
> > > here:
> > >
> > >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC1/CHANGES.md
> > >
> > > The RELEASENOTES.md are here:
> > >
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.1.2RC1/RELEASENOTES.md
> > >
> > > Please try out this candidate and vote +1/-1 on whether we should
> > > release these artifacts as HBase 2.1.2.
> > >
> > > The VOTE will remain open for at least 72 hours. Given sufficient votes
> > > I would like to close it on Sunday, January 6th, 2018.
> > >
> > > Thanks,
> > > S
> > > P.S. Happy New Year!
> > >
> >
>

Clean up old HBase jobs from builds.a.o

[Peter Somogyi]

There was an email from Infra[1] recently regarding some workspaces which
consume high disk space. Unfortunately the list contains many HBase related
jobs as well.

I went through on all of our jobs and many of these are disabled and
without a single run in the past year. My plan is to delete the jobs below
from builds.apache.org on Friday. Do you think we need any of these jobs so
I should keep them?

HBase-1.0
HBase-1.1
HBase-1.2
HBase-1.3
HBase-1.4
HBase-1.5
HBase-2.0
HBase-0.94
HBase-0.98
HBase-TRUNK
HBase-0.94.28
HBase-1.1-JDK7
HBase-1.1-JDK8
HBase-1.2-JDK7
HBase-1.2-JDK8
HBase-1.3-JDK7
HBase-1.3-JDK8
HBASE-16264
HBase-0.94-JDK7
HBase-0.98-matrix
HBase-HBASE-14614
HBase-Trunk_matrix
HBase-0.94-security
HBase-1.2 non-matrix
HBase-0.94-on-Hadoop-2
HBase-0.94.18-security
HBase-2.0-hadoop3-tests
HBase-0.98-on-Hadoop-1.1
HBASE-20112 (still active but change is merged in April 2018)
HBASE-20364 (still active but change is merged in April 2018)
HBASE-Flaky-Tests-branch2.0
HBase-Build-clusterdock-Clusters
HBase-Find-Flaky-Tests-branch2.0
HBase-Flaky-Tests-old-just-master

Thanks,
Peter

[1] https://s.apache.org/h0Hz

Re: [VOTE] The second release candidate for HBase 2.0.4 is available

[Peter Somogyi]

+1

Checksum, signature: OK
Build from source: OK
Unit tests: OK (TestVerifyReplication fails sporadically)
Apache Rat check: OK
Web UI: OK
LTT 1M rows: OK
Shell: OK

Thanks,
Peter

On Thu, Jan 3, 2019 at 7:29 AM Stack  wrote:

> Thanks for the ITBLL Allan.
>
> +1 from me too. Thats three binding +1s. Will leave it open another while
> in case anyone else wants to take a looksee.
>
> S
>
> On Sat, Dec 29, 2018 at 8:44 AM Stack  wrote:
>
> > The second release candidate for HBase 2.0.4 is available for download:
> >
> >  *https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC1/
> > *
> >
> > Maven artifacts are also available in a staging repository at:
> >
> >  https://repository.apache.org/content/repositories/orgapachehbase-1246
> >
> > Artifacts are signed with my key (DB9D313DA7874F29) published in our
> > KEYS file at http://www.apache.org/dist/hbase/KEYS
> >
> > The RC corresponds to the signed tag 2.0.4RC1, which currently points
> > to commit
> >
> >   205e39c5704bf38568b34926dde9f1ee76e6b5d0
> >
> > HBase 2.0.4 is the fourth maintenance release in the HBase 2.0 line,
> > continuing on the theme of bringing a stable, reliable database to
> > the Hadoop and NoSQL communities. It fixes a critical issue found
> > in the recent 2.0.3 and 2.1.1 releases (only), HBASE-21551. 2.0.4
> > includes ~31 bug and improvement fixes done since the 2.0.3,
> > ~ a month ago.
> >
> > The detailed source and binary compatibility report vs 2.0.3 has been
> > published for your review, at:
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC1/compatibility_report_2.0.3vs2.0.4.html
> >
> > The report shows no incompatibilities.
> >
> > The full list of fixes included in this release is available in
> > the CHANGES.md that ships as part of the release also available
> > here:
> >
> >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC1/CHANGES.md
> >
> > The RELEASENOTES.md are here:
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.4RC1/RELEASENOTES.md
> >
> > Please try out this candidate and vote +1/-1 on whether we should
> > release these artifacts as HBase 2.0.4.
> >
> > The VOTE will remain open for at least 72 hours. It'll probably take
> > longer given
> > its the holidays. I'll close the vote when sufficient votes after
> > Tuesday, January
> > 1st, 2019.
> >
> > Thanks,
> > S
> >
>

Re: Failure: hbase.apache.org HTML Checker

[Peter Somogyi]

The build failed because it tried to clone HBase repository from
git-wip-us. I missed to change this URL previously because it was not on
the HBase view, now it is there with hbase_generate_website job.
Just started a new build which already passed the phase where it failed
previously.

On Fri, Jan 11, 2019 at 8:20 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> Failure
>
> Either the Jenkins job failed, or (more likely) HTML errors were found.
>
> Unless the Jenkins job itself failed, the HTML and link-checking report
> for http://hbase.apache.org is available at
> https://builds.apache.org/job/HBase%20Website%20Link%20Checker/184/artifact/link_report/index.html
> .
>
> Otherwise, see
> https://builds.apache.org/job/HBase%20Website%20Link%20Checker/184/console
> .

Re: Clean up old HBase jobs from builds.a.o

[Peter Somogyi]

The jobs are deleted with the 2 branches.

On Wed, Jan 9, 2019 at 12:39 AM Stack  wrote:

> +1
>
> Thanks for doing this Peter.
>
> S
>
> On Tue, Jan 8, 2019 at 3:21 AM Peter Somogyi  wrote:
>
> > There was an email from Infra[1] recently regarding some workspaces which
> > consume high disk space. Unfortunately the list contains many HBase
> related
> > jobs as well.
> >
> > I went through on all of our jobs and many of these are disabled and
> > without a single run in the past year. My plan is to delete the jobs
> below
> > from builds.apache.org on Friday. Do you think we need any of these jobs
> > so
> > I should keep them?
> >
> > HBase-1.0
> > HBase-1.1
> > HBase-1.2
> > HBase-1.3
> > HBase-1.4
> > HBase-1.5
> > HBase-2.0
> > HBase-0.94
> > HBase-0.98
> > HBase-TRUNK
> > HBase-0.94.28
> > HBase-1.1-JDK7
> > HBase-1.1-JDK8
> > HBase-1.2-JDK7
> > HBase-1.2-JDK8
> > HBase-1.3-JDK7
> > HBase-1.3-JDK8
> > HBASE-16264
> > HBase-0.94-JDK7
> > HBase-0.98-matrix
> > HBase-HBASE-14614
> > HBase-Trunk_matrix
> > HBase-0.94-security
> > HBase-1.2 non-matrix
> > HBase-0.94-on-Hadoop-2
> > HBase-0.94.18-security
> > HBase-2.0-hadoop3-tests
> > HBase-0.98-on-Hadoop-1.1
> > HBASE-20112 (still active but change is merged in April 2018)
> > HBASE-20364 (still active but change is merged in April 2018)
> > HBASE-Flaky-Tests-branch2.0
> > HBase-Build-clusterdock-Clusters
> > HBase-Find-Flaky-Tests-branch2.0
> > HBase-Flaky-Tests-old-just-master
> >
> > Thanks,
> > Peter
> >
> > [1] https://s.apache.org/h0Hz
> >
>

Re: [DISCUSS] move to gitbox

[Peter Somogyi]

Created HBASE-21701 'Accept pull requests from contributors' and added to a
comment what was collected until now. Feel free to add more there!

On Wed, Jan 9, 2019 at 11:22 AM Tamas Penzes 
wrote:

> +1 for rebase and merge.
>
> It is the most understandable merge strategy. Others can cause huge
> confusion when checking the history.
>
> On Wed, Jan 9, 2019, 00:19 Ankit Singhal 
> > Just sharing what other communities are thinking on some of the merging
> > strategies provided by github for pull requests:-
> >
> >
> https://lists.apache.org/thread.html/c41aef9a33548de8e543d01611e71316c1cd0b0d0a75fb583d609ae1@%3Cdev.calcite.apache.org%3E
> >
> > "default merge pull request" option:-
> > Affects the linear history of the commits , it will be hard to follow
> which
> > is commit recently.
> > https://help.github.com/articles/about-pull-request-merges/
> >
> > "Squash merge" option:-
> > Calcite community is considering of disabling the feature from Github and
> > delegating it to the author to squash all their commit before it can be
> > merged by the committer so that original author of the PR can be
> preserved
> > in the squashed commit.
> >
> > "rebase and merge" option:-
> > This is how most of the apache projects currently doing through git
> client,
> > It will preserves the author and linear history of the commit.(also
> tested
> > by calcite community and said on below blog)
> > https://blog.github.com/2016-09-26-rebase-and-merge-pull-requests/
> >
> > So , we may should consider disabling the ones which doesn't suit us to
> > avoid committers using them accidentally.
> >
> > Regards,
> > Ankit Singhal
> >
> >
> > On Tue, Jan 8, 2019 at 11:07 AM Peter Somogyi 
> wrote:
> >
> > > I believe we reached consensus to migrate our remaining repositories to
> > > GitBox before the mandatory migration which will happen on 7th of
> > February.
> > > Apart from 'hbase' we still have 'hbase-site' and 'hbase-thirdparty'
> > > repositories that also require the same migration process.
> > >
> > > From users' point of view they could still use git://
> > > git.apache.org/hbase.git for read only access, only committers need to
> > > change the remote URL to the GitBox one. Jenkins jobs are already using
> > the
> > > GitHub URL for cloning the repository and I created a patch for the
> > > documentation and website changes in HBASE-21685 that we can merge
> after
> > > the process is competed.
> > >
> > > There's still outstanding work to do before we have good guidelines on
> > > accepting pull requests on GitHub, but the GitBox migration doesn't
> > require
> > > our committers to start working with PRs in a different way.
> > >
> > > If there is no disagreement I'd kindly ask one of the PMC members to
> > reach
> > > out to INFRA to perform the migration.
> > >
> > > Thanks,
> > > Peter
> > >
> > > On Sun, Dec 9, 2018 at 12:56 AM Andrew Purtell <
> andrew.purt...@gmail.com
> > >
> > > wrote:
> > >
> > > > Sounds good to me except squash merge at commit of PR shouldn’t be an
> > > > option it should be required except for good reason (and I don’t know
> > > what
> > > > that would be )
> > > >
> > > > > On Dec 8, 2018, at 3:28 PM, Stack  wrote:
> > > > >
> > > > >> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey 
> > wrote:
> > > > >>
> > > > >> The move to gitbox doesn't require us to only accept github PRs.
> > Given
> > > > >> the current rate of contributions via patches on JIRA vs GitHub
> > PRs, I
> > > > >> wouldn't want to push for that now.
> > > > >>
> > > > >> The change does make it easier for us to start encouraging PR
> > > > >> submissions, because committers will be able to directly merge
> from
> > > > >> the GitHub UI.
> > > > >>
> > > > >> I'd recommend we try to keep this as a small incremental change.
> > That
> > > > >> would mean:
> > > > >>
> > > > >> * committers ensure there's an associated JIRA for release note
> and
> > > > >> precommit checks (that can be just by pinging the contributor to
> go
> > > > >> make one)
> > > > >> * backports are still handled by the

Re: Clean up old HBase jobs from builds.a.o

[Peter Somogyi]

Sure, I can also delete the 2 branches if I have permission for it.

On Tue, Jan 8, 2019 at 12:48 PM 张铎(Duo Zhang)  wrote:

> +1 on removing them all. And for the two merged branch, let's also down a
> push to delete them?
>
> Peter Somogyi  于2019年1月8日周二 下午7:21写道：
>
> > There was an email from Infra[1] recently regarding some workspaces which
> > consume high disk space. Unfortunately the list contains many HBase
> related
> > jobs as well.
> >
> > I went through on all of our jobs and many of these are disabled and
> > without a single run in the past year. My plan is to delete the jobs
> below
> > from builds.apache.org on Friday. Do you think we need any of these jobs
> > so
> > I should keep them?
> >
> > HBase-1.0
> > HBase-1.1
> > HBase-1.2
> > HBase-1.3
> > HBase-1.4
> > HBase-1.5
> > HBase-2.0
> > HBase-0.94
> > HBase-0.98
> > HBase-TRUNK
> > HBase-0.94.28
> > HBase-1.1-JDK7
> > HBase-1.1-JDK8
> > HBase-1.2-JDK7
> > HBase-1.2-JDK8
> > HBase-1.3-JDK7
> > HBase-1.3-JDK8
> > HBASE-16264
> > HBase-0.94-JDK7
> > HBase-0.98-matrix
> > HBase-HBASE-14614
> > HBase-Trunk_matrix
> > HBase-0.94-security
> > HBase-1.2 non-matrix
> > HBase-0.94-on-Hadoop-2
> > HBase-0.94.18-security
> > HBase-2.0-hadoop3-tests
> > HBase-0.98-on-Hadoop-1.1
> > HBASE-20112 (still active but change is merged in April 2018)
> > HBASE-20364 (still active but change is merged in April 2018)
> > HBASE-Flaky-Tests-branch2.0
> > HBase-Build-clusterdock-Clusters
> > HBase-Find-Flaky-Tests-branch2.0
> > HBase-Flaky-Tests-old-just-master
> >
> > Thanks,
> > Peter
> >
> > [1] https://s.apache.org/h0Hz
> >
>

Re: Are we ready to accept PR commit from github?

[Peter Somogyi]

t; >>> >
> > >  > >>>
> > >  >
> > >
> >
> https://lists.apache.org/thread.html/c441a64c28547ca405b65ad97a7dc78601d33149eb8fcc64aee88eeb@%3Cbuilds.apache.org%3E
> > >  > >>> >
> > >  > >>>
> > >  >
> > >
> >
> https://lists.apache.org/thread.html/a21448239fe5dab8a486df72f032d84aade7425d1dac625b0410b63c@%3Cbuilds.apache.org%3E
> > >  > >>> >
> > >  > >>> > ChrisT gave me the necessary clarification to get things
> > > working.
> > >  > >>> > Hopefully between our current Jenkins automation and the
> > > job I sent
> > >  > >>> > below, it'd be enough to get something functional if you
> > > have the
> > >  > time
> > >  > >>> > to devote to it :)
> > >  > >>> >
> > >  > >>> > On 3/15/19 10:40 AM, Josh Elser wrote:
> > >  > >>> > > I went through this exercise recently, trying to get it
> > > set up for
> > >  > >>> Ratis:
> > >  > >>> > >
> > >  > >>> > > The result is at
> > >  > >>> > >
> > >  >
> > https://builds.apache.org/job/PreCommit-RATIS-github-pull-requests/
> > >  > >>> > >
> > >  > >>> > > Infra has docs up at
> > >  > >>> > >
> > >  > >>>
> > >  >
> > >
> >
> https://cwiki.apache.org/confluence/display/INFRA/GitHub+Pull+Request+Builder
> > >  > >>> .
> > >  > >>> > > I remember them not being 100% accurate but I'm having
> > > trouble
> > >  > >>> finding
> > >  > >>> > > the thread where I was talking to them about this. Will
> > > write back
> > >  > >>> if I
> > >  > >>> > > find it.
> > >  > >>> > >
> > >  > >>> > > On 3/15/19 12:14 AM, Yu Li wrote:
> > >  > >>> > >> I'm afraid not for driving this but yes to offer a hand
> > > (smile).
> > >  > >>> > >>
> > >  > >>> > >> Is there already some planned steps ongoing? Infra
> setup
> > is
> > >  > >>> something I'm
> > >  > >>> > >> not familiar but required for pre-commit and daily
> check
> > on
> > >  > Travis,
> > >  > >>> other
> > >  > >>> > >> than that just count me in and let me know what I could
> > > do to
> > >  > help.
> > >  > >>> > >>
> > >  > >>> > >> Best Regards,
> > >  > >>> > >> Yu
> > >  > >>> > >>
> > >  > >>> > >>
> > >  > >>> > >> On Thu, 14 Mar 2019 at 21:26, 张铎(Duo Zhang) <
> > >  > palomino...@gmail.com <mailto:palomino...@gmail.com>>
> > >  > >>> > >> wrote:
> > >  > >>> > >>
> > >  > >>> > >>> I think PR will be good. Do you have any cycle to
> drive
> > > this Yu
> > >  > Li?
> > >  > >>> > >>> Thanks.
> > >  > >>> > >>>
> > >  > >>> > >>> Yu Li mailto:car...@gmail.com>> 于
> > > 2019年3月14日周四 下午8:53写道：
> > >  > >>> > >>>
> > >  > >>> > >>>> I see, thanks for the quick response Peter.
> > >  > >>> > >>>>
> > >  > >>> > >>>> Best Regards,
> > >  > >>> > >>>> Yu
> > >  > >>> > >>>>
> > >  > >>> > >>>>
> > >  > >>> > >>>> On Thu, 14 Mar 2019 at 17:38, Peter Somogyi <
> > >  > psomo...@apache.org <mailto:psomo...@apache.org>>
> > >  > >>> > >>>> wrote:
> > >  > >>> > >>>>
> > >  > >>> > >>>>> For hbase repository we do not yet have the
> > > integration to
> > >  > >>> accept pull
> > >  > >>> > >>>>> requests but hbase-connectors and
> hbase-operator-tools
> > >  > >>> repositories
> > >  > >>> > >>> moved
> > >  > >>> > >>>>> to GitHub PR workflow instead of accepting patch
> > files.
> > >  > >>> > >>>>>
> > >  > >>> > >>>>> Peter
> > >  > >>> > >>>>>
> > >  > >>> > >>>>> On Thu, Mar 14, 2019 at 9:42 AM Yu Li
> > > mailto:car...@gmail.com>>
> > >  > wrote:
> > >  > >>> > >>>>>
> > >  > >>> > >>>>>> Hi All,
> > >  > >>> > >>>>>>
> > >  > >>> > >>>>>> Please forgive me if this is already clearly
> > > clarified in
> > >  > other
> > >  > >>> mail
> > >  > >>> > >>>>>> threads, but last time when I saw discussion about
> > > this we
> > >  > were
> > >  > >>> still
> > >  > >>> > >>>>>> lacking some INFRA support to accept PR from
> github,
> > > so I'd
> > >  > >>> like to
> > >  > >>> > >>>>> double
> > >  > >>> > >>>>>> check here. Many thanks.
> > >  > >>> > >>>>>>
> > >  > >>> > >>>>>> Best Regards,
> > >  > >>> > >>>>>> Yu
> > >  > >>> > >>>>>>
> > >  > >>> > >>>>>
> > >  > >>> > >>>>
> > >  > >>> > >>>
> > >  > >>> > >>
> > >  > >>>
> > >  > >>
> > >  >
> > >
> >
>

[VOTE] Send GitHub notification to issues@hbase

[Peter Somogyi]

Hi,

Right now notification emails from GitHub activities are sent to dev@hbase
for https://github.com/apache/hbase repository. Nick Dimiduk had a
suggestion that these should be forwarded to a different hbase mailing list.

Since these kinds of emails are already sent to issues@hbase for the rest
of our repositories (hbase-operator-tools, hbase-connectors and hbase-site)
I recommend doing the same for hbase as well.

Please vote whether you agree to make the change or you're against it.

Thanks,
Peter

Re: Failure: HBase Generate Website

[Peter Somogyi]

Issue is fixed and the new job succeeded.

On Tue, Mar 26, 2019 at 3:34 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> Build status: Failure
>
> The HBase website has not been updated to incorporate HBase commit
> ${CURRENT_HBASE_COMMIT}.
>
> See https://builds.apache.org/job/hbase_generate_website/1627/console

Re: [DISCUSS] EOL for branch-1.2

[Peter Somogyi]

+1 on EOL 1.2.

I believe the notices in the announcement emails were adequate and by
retiring branch-1.2 we are also moving forward to achieve our goal to
reduce the number of active branches.

Thanks for your work Sean on HBase 1.2!

On Sat, Apr 6, 2019 at 3:35 AM Sean Busbey  wrote:

> Hi folks!
>
> Back when our stable pointer first moved off of branch-1.2 releases I
> said I'd do ~6 months of releases[1]. I'm preparing an RC for the
> 1.2.12 release[2] and it's been ~6.5 months.
>
> I intend 1.2.12 to be the last release I manage off of branch-1.2. If
> anyone else sees a reason to keep this release line going and is
> willing to step in as RM please speak up.
>
> This is the template for the notice that's been in the ANNOUNCE emails
> for 1.2.7 - 1.2.11:
>
> > All users of previous 1.2.z releases are encouraged to upgrade to either
> > this release or the latest in our stable release line, which is currently
> > X.Y.Z. Releases in the 1.2.z line are expected to stop in late spring
> 2019.
>
>
> Presuming no one wants to keep things going by the time a 1.2.12 VOTE
> passes, I'll modify it to say the branch is EOL. About a month later
> I'll do a dedicated EOL post to user@hbase, clean up project
> references to the release line, and then remove the release from
> dist.apache.org (it will remain along with all the others on
> archive.apache.org).
>
> [1]: https://s.apache.org/UEPy
> [2]: https://issues.apache.org/jira/browse/HBASE-22171
>

Re: [VOTE] Send GitHub notification to issues@hbase

[Peter Somogyi]

> Will dev@ still get notified when new issues are opened? Or not at all?
I forwarded the question to INFRA.

On Thu, Mar 28, 2019 at 7:09 AM Yu Li  wrote:

> +1
>
> Best Regards,
> Yu
>
>
> On Thu, 28 Mar 2019 at 08:50, Zach York 
> wrote:
>
> > Will dev@ still get notified when new issues are opened? Or not at all?
> >
> > +1 if dev@ still gets notified when new issues are opened (how it
> > currently
> > works with JIRA)
> >
> > On Wed, Mar 27, 2019 at 5:34 PM Andrew Purtell 
> > wrote:
> >
> > > +1
> > >
> > >
> > > On Wed, Mar 27, 2019 at 12:29 PM Peter Somogyi 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Right now notification emails from GitHub activities are sent to
> > > dev@hbase
> > > > for https://github.com/apache/hbase repository. Nick Dimiduk had a
> > > > suggestion that these should be forwarded to a different hbase
> mailing
> > > > list.
> > > >
> > > > Since these kinds of emails are already sent to issues@hbase for the
> > > rest
> > > > of our repositories (hbase-operator-tools, hbase-connectors and
> > > hbase-site)
> > > > I recommend doing the same for hbase as well.
> > > >
> > > > Please vote whether you agree to make the change or you're against
> it.
> > > >
> > > > Thanks,
> > > > Peter
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >- A23, Crosstalk
> > >
> >
>

Re: Request for an invite to Slack Channel

[Peter Somogyi]

I sent an invitation to your @apache address.

On Thu, Mar 28, 2019 at 1:32 AM Sergey Shelukhin
 wrote:

> Can I have one too? :)
>
> -Original Message-
> From: William Shen 
> Sent: Tuesday, March 5, 2019 2:57 PM
> To: dev@hbase.apache.org
> Subject: Re: Request for an invite to Slack Channel
>
> I've sent an invite to you, Dmitriy.
>
> On Tue, Mar 5, 2019 at 9:47 AM Dmitriy Kuharev <
> dmitriy.kuha...@ultratendency.com> wrote:
>
> > Hello,
> >
> > I would like to join the discussion in your slack channel. I have a
> > few questions about submitting changes.
> >
> > Best Regards,
> > Dmitriy.
> >
>

Re: [VOTE] HBase Thirdparty 2.2.0 RC1

[Peter Somogyi]

+1

Checked signature, checksum
Built from source
Ran Apache Rat check
Ran HBase master tests using this RC
Checked CHANGES and RELEASENOTES


On Sat, Mar 30, 2019 at 10:14 PM Stack  wrote:

> Please consider the following as the 2.2.0 release of Apache HBase
> Thirdparty. It is the second release candidate for your consideration.
>
> It is a year since our 2.1.0 release. 2.2.0 updates some of our core
> dependencies:
>
>  gson 2.8.1 -> 2.8.5
>  guava 22.0 -> 27.1-jre
>  pb 3.5.1 -> 3.7.0
>  netty 4.1.17 -> 4.1.34
>  commons-collections4 4.1 -> 4.3
>
> The coming hbase-2.2.0 RC would like to include an updated
> hbase-thirdparty.
>
> Source artifact, signatures, checksums, and changes are available at:
>
>
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-thirdparty/hbase-thirdparty-2.2.0RC1/
>
> The release was made against tag 2.2.0RC0. It was signed with my key
> 'st...@duboce.net' which can be found here:
>
>  https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> Maven staging repository is available at:
>
>  https://repository.apache.org/content/repositories/orgapachehbase-1297
>
> This vote will remain open for at least 72 hours.
>
> Yours,
> Your HBase Release Manager
>

[NOTICE] Disabling Website Link Checker job

[Peter Somogyi]

Hi,

I'm disabling HBase Website Link Checker job [1] on Jenkins since it
produces incorrect result (HBASE-21569); the site has a bunch of invalid
links and anchors that the tool finds; and the build time for this report
is 16 hours every week.
The job can be launched manually by committers if needed.

Peter

[1]
https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Website%20Link%20Checker/

Re: View on version EOLs

[Peter Somogyi]

The current plan is to retire 2.0. The voting is in progress for 2.0.5 and
more releases are not planned unless critical bugs are discovered.

On the 1.3 line there was a discussion for EOL, but the Francis (RM) would
like to continue that.

HBase 1.5.0 is coming up shortly and you could also expect more bugfix
releases on 1.2.

On Thu, Feb 28, 2019 at 6:38 AM Nikhil Bafna  wrote:

> We run Hbase 1.2.x in our production that has a set of patches & backports.
>
> In the mailing list, I see discussions for EOL of 1.3 & 2.0.x. In another
> mailing list discussion, it was pointed out that "... targeting only bug
> fixes for branch-1, as version 1 approaches EOL"
>
> But, I see new releases happening on 1.2.x versions - which seems to be
> contradictory.
>
> What are the EOL plans for the active versions?
>

Re: The third HBase 1.5.0 release candidate (RC2) is available

[Peter Somogyi]

+1

Checksums, signatures: OK
Build from source: OK
Unit tests: OK
Rat check: OK
LTT 1M rows: OK
Basic shell commands: OK
Master, RegionServer UI: OK
Logs: OK

On Thu, Feb 28, 2019 at 7:17 PM Andrew Purtell  wrote:

> We have one binding vote so far, need two more.
> Thanks for the nonbinding vote, Xu.
>
> I have not yet had time to do the performance testing as promised, so let
> me extend the vote for a week. I will try to close it end of next week.
>
>
> On Thu, Feb 21, 2019 at 3:44 PM Andrew Purtell 
> wrote:
>
> > The third HBase 1.5.0 release candidate (RC2) is available for download
> at
> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.5.0RC2/ and Maven
> > artifacts are available in the temporary repository
> > https://repository.apache.org/content/repositories/orgapachehbase-1258/
> >
> > The git tag corresponding to the candidate is '1.5.0RC2' (b5c50b506c).
> >
> > A detailed source and binary compatibility report for this release is
> > available for your review at
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.5.0RC2/compat-check-report.html
> > .
> >
> > A list of the 94 issues resolved in this release can be found at
> > https://s.apache.org/K4Wk . The 1.5.0 changelog is derived from the
> > changelog of the last branch-1.4 release, 1.4.9.
> >
> > Please try out the candidate and vote +1/0/-1.
> >
> > The vote will be open for at least 72 hours. Unless objection I will try
> > to close it Thursday February 28, 2019 if we have sufficient votes.
> >
> > Prior to making this announcement I made the following preflight checks:
> >
> > RAT check passes (7u80)
> > Unit test suite passes (7u80, 8u181)*
> > Opened the UI in a browser, poked around
> > LTT load 100M rows with 100% verification and 20% updates (8u181)
> > ITBLL 1B rows with slowDeterministic monkey (8u181)
> > ITBLL 1B rows with serverKilling monkey (8u181)
> >
> > Some of this testing was done with recent 1.5.0-SNAPSHOT versions. During
> > the month of February I plan to perform a number of additional tests,
> > including performance regression checks. As more results become
> available I
> > will post them to this thread.
> >
> > There are known flaky tests. See HBASE-21904 and HBASE-21905. These flaky
> > tests do not represent serious test failures that would prevent a release
> > in my opinion.
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> >
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [VOTE] First release candidate for HBase 2.0.5 is available

[Peter Somogyi]

-0

Revision is empty:
Software Attribues on UI:
HBase Version 2.0.5, revision= HBase version and revision

Shell startup
$ bin/hbase shell
2019-03-04 14:31:13,174 WARN  [main] util.NativeCodeLoader: Unable to load
native-hadoop library for your platform... using builtin-java classes where
applicable
HBase Shell
Use "help" to get list of supported commands.
Use "exit" to quit this interactive shell.
For Reference, please visit: http://hbase.apache.org/2.0/book.html#shell
Version 2.0.5, r, Thu Feb 28 06:50:13 UTC 2019
Took 0.0022 seconds


hbase(main):001:0>

Other tests performed:
Build from source: OK
Unit test: OK
Rat check: OK
LTT 1M rows: OK
Shell commands: OK

On Mon, Mar 4, 2019 at 1:26 AM 张铎(Duo Zhang)  wrote:

> Please see the last few comments on HBASE-21960, I wonder if the hadoop3
> compatibility has been broken...
>
> Stack  于2019年3月2日周六 下午1:13写道：
>
> > Thanks Josh for giving it a go.
> >
> > Let me fix the KEYs link (trying to automate this stuff
> > HBASE-21935... let me fix my link mistake in email template).
> >
> > I think the signing key is in KEYS -- its just toward the end obscured by
> > stale keys of mine. Let me remove the old ones and try and make the email
> > clearer.
> >
> > Thanks,
> > S
> >
> >
> >
> > On Fri, Mar 1, 2019 at 2:53 PM Josh Elser  wrote:
> >
> > > +1 (binding)
> > >
> > > Built and ran through a good number of the unit tests (before laptop
> > > went to sleep). xsums and sigs are good after I got your new key.
> > >
> > > I see you listed https://dist.apache.org/repos/dist/dev/hbase/KEYS
> > > below, but this file doesn't exist. Looking at svn-log, I don't see an
> > > update from you to dist/release/hbase/KEYS. Can you double-check you
> > > have your new one on ASF infra, please? I was able `gpg --recv-keys`
> and
> > > validate your signatures.
> > >
> > > Ran through some brief PE exercises locally. Validated the fix for
> > > HBASE-21960.
> > >
> > > - Josh
> > >
> > > On 2/28/19 2:41 PM, Stack wrote:
> > > > Please vote on this release candidate (RC) for Apache HBase 2.0.5.
> > > > Our intent is that this will be the last release of the branch-2.0
> > line.
> > > > If running on a HBase-2.0.x release, please move to a later release.
> > > >
> > > > The VOTE will remain open for at least 72 hours.
> > > >
> > > > [ ] +1 Release this package as Apache HBase 2.0.5
> > > > [ ] -1 Do not release this package because ...
> > > >
> > > > The tag to be voted on is 2.0.5RC0 (commit
> > > > 66a8972677645997c43df19457d61589817cd324):
> > > >
> > > >   https://github.com/apache/hbase/tree/2.0.5RC0
> > > >
> > > > The release files, including signatures, digests, etc. can be found
> at:
> > > >
> > > >   https://dist.apache.org/repos/dist/dev/hbase/2.0.5RC0/
> > > >
> > > > Maven artifacts are available in a staging repository at:
> > > >
> > > >
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1285/
> > > >
> > > > Signatures used for HBase RCs can be found in this file:
> > > >
> > > >   https://dist.apache.org/repos/dist/dev/hbase/KEYS
> > > >
> > > > The list of bug fixes going into {version} can be found in included
> > > > CHANGES.md and RELEASENOTES.md available here:
> > > >
> > > >   https://dist.apache.org/repos/dist/dev/hbase/2.0.5RC0/CHANGES.md
> > > >
> > https://dist.apache.org/repos/dist/dev/hbase/2.0.5RC0/RELEASENOTES.md
> > > >
> > > > To learn more about Apache HBase, please see
> http://hbase.apache.org/
> > > >
> > > > Thanks,
> > > > Your HBase Release Manager
> > > >
> > >
> >
>

Re: View on version EOLs

[Peter Somogyi]

Both branch 1 and 2 will continue to have new releases where new features
can be integrated, although, most of the contributions are shifting towards
branch-2 lately.

We're looking forward to your contributions!

Peter

On Mon, Mar 4, 2019 at 4:38 PM Nikhil Bafna
 wrote:

> So, are there any 1.x branches that are continuing to get new features?
>
> Looking at a 6 month view, should we (Flipkart) rather plan to develop (and
> start contributing) on 2.x branch, instead of 1.x branches?
>
>
> --
> Nikhil Bafna | 8095234263
>
>
> On Fri, Mar 1, 2019 at 4:43 PM Peter Somogyi  wrote:
>
> > The current plan is to retire 2.0. The voting is in progress for 2.0.5
> and
> > more releases are not planned unless critical bugs are discovered.
> >
> > On the 1.3 line there was a discussion for EOL, but the Francis (RM)
> would
> > like to continue that.
> >
> > HBase 1.5.0 is coming up shortly and you could also expect more bugfix
> > releases on 1.2.
> >
> > On Thu, Feb 28, 2019 at 6:38 AM Nikhil Bafna  wrote:
> >
> > > We run Hbase 1.2.x in our production that has a set of patches &
> > backports.
> > >
> > > In the mailing list, I see discussions for EOL of 1.3 & 2.0.x. In
> another
> > > mailing list discussion, it was pointed out that "... targeting only
> bug
> > > fixes for branch-1, as version 1 approaches EOL"
> > >
> > > But, I see new releases happening on 1.2.x versions - which seems to be
> > > contradictory.
> > >
> > > What are the EOL plans for the active versions?
> > >
> >
>

Re: Are we ready to accept PR commit from github?

[Peter Somogyi]

For hbase repository we do not yet have the integration to accept pull
requests but hbase-connectors and hbase-operator-tools repositories moved
to GitHub PR workflow instead of accepting patch files.

Peter

On Thu, Mar 14, 2019 at 9:42 AM Yu Li  wrote:

> Hi All,
>
> Please forgive me if this is already clearly clarified in other mail
> threads, but last time when I saw discussion about this we were still
> lacking some INFRA support to accept PR from github, so I'd like to double
> check here. Many thanks.
>
> Best Regards,
> Yu
>

Re: Failure: HBase Generate Website

[Peter Somogyi]

Yes, git version is 2.7.4 which does not support --no-show-signature.

On Thu, Mar 7, 2019 at 5:27 PM Sean Busbey  wrote:

> ah, by "malformed" I of course mean missing entirely. yeah this is a
> result of HBASE-21999. since we exit before creating the Version class
> definition at all when the git revision is blank. We must have been
> creating an hbase build with unknown revisions for some time.
>
>
>
> On Thu, Mar 7, 2019 at 10:20 AM Sean Busbey  wrote:
> >
> > Building is failing because the generated Version class is malformed.
> >
> > Looking at the changeset, maybe HBASE-21999 is to blame?
> >
> > On Thu, Mar 7, 2019 at 8:31 AM Apache Jenkins Server
> >  wrote:
> > >
> > > Build status: Failure
> > >
> > > The HBase website has not been updated to incorporate HBase commit
> ${CURRENT_HBASE_COMMIT}.
> > >
> > > See https://builds.apache.org/job/hbase_generate_website/1610/console
>

Re: [DISCUSS] HBASE-14850 C++ client implementation

[Peter Somogyi]

+1 for hbase-native-client repo.
You can create a new gitbox repository on https://gitbox.apache.org/ by
filling out a simple form.

On Wed, Mar 20, 2019 at 8:48 AM Guanghao Zhang  wrote:

> I am +1 to push the hbase-native-client to a new git repo. One more
> question, how to create a new repo in gitbox? Do we have some ref guide for
> this? Thanks.
>
> Sean Busbey  于2019年3月14日周四 下午9:58写道：
>
> > I'd also like to see the native client in its own repo. Dealing with a
> > new build system for C++ will be some overhead, but I suspect less
> > overhead than if we have to stitch that build to work with maven in
> > the same repo.
> >
> > Also I think the hbase-connectors repo is overdue for a release and
> > I'd rather avoid either rushing the C++ client, blocking to wait for
> > it, or doing the work to pull it aside when doing a release.
> >
> > On Thu, Mar 14, 2019 at 8:28 AM 张铎(Duo Zhang) 
> > wrote:
> > >
> > > For hbase-connectors, it is still a maven project, but the native
> client
> > is
> > > a C++ project, so maybe we could just give it a separated repo...
> > >
> > > Stack  于2019年3月14日周四 下午1:54写道：
> > >
> > > > On Wed, Mar 13, 2019 at 12:54 AM Guanghao Zhang 
> > > > wrote:
> > > > ...
> > > >
> > > > > As we have hbase-connectors project now and Sean Busbey suggested
> to
> > move
> > > > > the native client to hbase-connector project. Or we can create a
> new
> > > > > project hbase-native-client for this. But the problem is the
> > > > compatibility
> > > > > may be break when there are some changes in HBase project. Looking
> > > > forward
> > > > > to your suggestions.
> > > > >
> > > >
> > > > Would hbase-native-client be in hbase-connectors? I'd imagine this
> > would
> > > > make the development easier.
> > > >
> > > > Once you'd made a release of the new client, could we a step to the
> > nightly
> > > > build that pulls the new client and runs it through paces complaining
> > if it
> > > > fails?
> > > >
> > > > (sounds great)
> > > > S
> > > >
> >
>

Re: [VOTE] Second release candidate for HBase 2.0.5 is available

[Peter Somogyi]

+1

Checked signature, checksums
Apache Rat check
Build from source
Run all tests (2 flaky failures, not reproducible)
LTT 1M rows
Tested simple shell commands
Checked master and RS UI
Reviewed change log and release note

On Mon, Mar 18, 2019 at 7:19 PM Stack  wrote:

> Please vote on this Apache HBase release candidate (RC), 2.0.5.
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache HBase 2.0.5
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.0.5RC1:
>
>  https://github.com/apache/hbase/tree/2.0.5RC1
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
>  https://dist.apache.org/repos/dist/dev/hbase/2.0.5RC1/
>
> Maven artifacts are available in a staging repository at:
>
>  https://repository.apache.org/content/repositories/orgapachehbase-1287/
>
> Artifacts were signed with the st...@duboce.net key which can be found in:
>
>  https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> To learn more about Apache HBase, please see http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>