[jira] [Resolved] (HBASE-10504) Define Replication Interface

2017-09-18 Thread stack (JIRA) 

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

stack resolved HBASE-10504.
---
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.0.0

Marking as 'done' in 2.0.0.

HBASE-18846 is the follow-on for hbase-indexer

> Define Replication Interface
> 
>
> Key: HBASE-10504
> URL: https://issues.apache.org/jira/browse/HBASE-10504
> Project: HBase
>  Issue Type: Task
>  Components: Replication
>Reporter: stack
>Assignee: Enis Soztutar
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: hbase-10504_v1.patch, hbase-10504_wip1.patch
>
>
> HBase has replication.  Fellas have been hijacking the replication apis to do 
> all kinds of perverse stuff like indexing hbase content (hbase-indexer 
> https://github.com/NGDATA/hbase-indexer) and our [~toffer] just showed up w/ 
> overrides that replicate via an alternate channel (over a secure thrift 
> channel between dcs over on HBASE-9360).  This issue is about surfacing these 
> APIs as public with guarantees to downstreamers similar to those we have on 
> our public client-facing APIs (and so we don't break them for downstreamers).
> Any input [~phunt] or [~gabriel.reid] or [~toffer]?
> Thanks.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type

2017-09-18 Thread stack (JIRA) 
stack created HBASE-18846:
-

 Summary: Accommodate the hbase-indexer/lily/SEP consumer 
deploy-type
 Key: HBASE-18846
 URL: https://issues.apache.org/jira/browse/HBASE-18846
 Project: HBase
  Issue Type: Bug
Reporter: stack


This is a follow-on from HBASE-10504, Define a Replication Interface. There we 
defined a new, flexible replication endpoint for others to implement but it did 
little to help the case of the lily hbase-indexer. This issue takes up the case 
of the hbase-indexer.

The hbase-indexer poses to hbase as a 'fake' peer cluster. The hbase-indexer 
will start up cut-down "RegionServer" processes that are nought but an hbase 
RpcServer hosting an AdminProtos Service. They make themselves 'appear' to the 
Replication Source by hoisting up an ephemeral znode 'registering' as a 
RegionServer. The source cluster then streams WALEdits to the Admin Protos 
method:

{code}
 public ReplicateWALEntryResponse replicateWALEntry(final RpcController 
controller,
  final ReplicateWALEntryRequest request) throws ServiceException {
{code}

The hbase-indexer relies on other hbase internals like Server so it can get a 
ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.

Thoughts on how to proceed include:
 
* Better formalize its current digestion of hbase internals; make it so 
rpcserver is allowed to be used by others, etc.
* Start an actual RegionServer only have it register the AdminProtos Service 
only -- not AdminProtos and ClientProtos, etc. Then have the hbase-indexer 
implement an AdminCoprocessor to override the replicateWALEntry method (the 
Admin CP implementation may need work).

I'll be back



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: DISCUSS: How can we have less branches?

2017-09-18 Thread Andrew Purtell 
I'm going to do a monthly cadence with 1.4. 

It's a bit delayed getting off the ground sadly because I need to address 
Francis' feedback and otherwise get RSGroups in before cutting the first RC, 
and I was recently out for two weeks on vacation. Soon, though. 

Or, we can start spinning minors off of branch-1 with the same cadence: 1.4.0, 
then 1.5.0, 1.6.0. Monthly or bi-monthly. Versions are cheap. Releasing minors 
would keep branch-1 in a good state and give us more flexibility for making 
changes (at the possible detriment of downstreamers we might break with LP 
changes, so hopefully we can be better about that). If we go this route I Will 
probably also maintain patch versions for 1.4 because our production will move 
up on it for a while. 

We will have to convince ourselves the issues with locking introduced in 1.3 
have settled before moving the stable pointer beyond 1.2. 


> On Sep 18, 2017, at 9:07 PM, Nick Dimiduk  wrote:
> 
> Reviving this thread. I know our interest is around branch-2 right now, but
> I think we are close to an actionable resolution here.
> 
> I'm a fan of Andrew's proposal of stabilizing our branch-1 for maintenance
> releases, getting away from all the minors if we can. Do we have a quorum
> of folks able and willing to do that work? Seems like it would center
> around the 1.4 release.
> 
> If branch-1.1 retires in the next 2-6 months, are we happy with branch-1.2,
> branch-1.3, or branch-1.4 carrying on the monthly cadence? Do we have a
> strong need to continue 1.x once 2.x is out? Are we calling 1.2 the LTS
> with quarterly patch releases, 1.3 aborted on arrival, and pushing folks
> onto 2.x? Do we want to settle on quarterly or bi-annual minor releases and
> only patch monthly or as necessary in between?
> 
> Thanks,
> Nick
> 
>> On Wed, Aug 9, 2017 at 8:00 AM, Mike Drob  wrote:
>> 
>> One thing that we need to be super careful about after releasing 2.0 is
>> that we don't accidentally introduce any incompatible changes. It's much
>> harder to reason about forwards compatibility than backwards compatibility
>> in my experience. So even though a hypothetical 1.5 would be released after
>> 2.0, users would still have the expectation that a 1.5->2.0 upgrade would
>> be smooth (unless we explicitly message that it isn't but that is a whole
>> new set of problems).
>> 
>> Also, to clarify some context here -- what is the difference between an LTS
>> branch and a Stable branch? Don't they convey the same thing to users? As a
>> relative newcomer, I feel like I missed an earlier conversation about this.
>> 
>> Mike
>> 
>>> On Tue, Aug 8, 2017 at 10:45 PM, Phil Yang  wrote:
>>> 
>>> Another option is no 1.5/branch-1 any more. What new features we are
>> going
>>> to have in HBase 1.5 (if it will be released)? Backporting from branch-2
>> to
>>> branch-1 is not easy, so maybe we will not have any big feature in
>> branch-1
>>> after releasing 1.4. And if we release 1.5 after releasing 2.0, it may
>>> confuse users. So IMO we can focus on branch-2 for new features.
>>> 
>>> I think it will be good if we have fixed logic for EOL branches, for
>>> example(just an example, can discuss):
>>> 1:Release a final version and EOL 1.x after we think 1.x+1 is stable.
>>> 2:Cut off new 1.x+2 branch after 1.x+1 is stable, don't cut too early.
>>> 
>>> Then we will not need discussing each time for each branch EOL and we
>> will
>>> have a fixed number of maintaining branches.
>>> 
>>> Thanks,
>>> Phil
>>> 
>>> 
>>> 2017-08-09 1:44 GMT+08:00 Andrew Purtell :
>>> 
 Well you are not wrong that branching was premature, it turns out. But
>>> I'll
 roll with it...
 
 
 On Tue, Aug 8, 2017 at 10:43 AM, Zach York <
>> zyork.contribut...@gmail.com
 
 wrote:
 
>> I made branch-1.4 a few weeks ago only.
> 
> Whoops, sorry for that! For some reason I thought I had seen it
>> months
 ago.
> 
> On Tue, Aug 8, 2017 at 10:40 AM, Andrew Purtell >> 
> wrote:
> 
>> +1 from me on making 1.1 our LTS. Either 1.1 or 1.2 are
>> candidates. I
> think
>> 1.1 has the edge because it lacks locking changes introduced into
>>> 1.2,
> just
>> like 1.2 lacks locking changes introduced in 1.3 - the latter of
>>> which
> has
>> had far reaching consequences, and the former not an insignificant
 change
>> either.
>> 
>> 
>> 
>> On Tue, Aug 8, 2017 at 10:31 AM, Nick Dimiduk 
> wrote:
>> 
>>> On Tue, Aug 8, 2017 at 9:15 AM Mike Drob 
>> wrote:
>>> 
> The discussion also brought up the notion of an LTS release
>>> line.
> I'm
>>> not
> sure how this jives with the more fequent minors, but would
 require
>>> some
> branch that's so stable that an RM can effectively spin
>>> releases
>> blind.
 
 Seems

Post-release RM duties

2017-09-18 Thread Nick Dimiduk 
Heya,

I noticed tonight that I've been remiss in closing tickets after the dust
settles around a release. I think it's something I/we did, once upon a
time. However, I don't see any mention of it in the ref guide around
releases. Is this something that should be done? Can you point me to our
existing policy on this? I'm happy to go back through and close out
tickets, just give me the affirmative on it being policy we want enforced.

For that matter I don't see much of anything in the way of guidelines for
RMs re: post-release processing. Seems worthy of a new section. I have my
post-VOTE steps outlined at the bottom of my crib sheet [0]. Should I/we
flesh this out in our documentation?

Thanks,
Nick

[0]: https://gist.github.com/ndimiduk/924db7f5ee75baa67802

Re: DISCUSS: How can we have less branches?

2017-09-18 Thread Nick Dimiduk 
Reviving this thread. I know our interest is around branch-2 right now, but
I think we are close to an actionable resolution here.

I'm a fan of Andrew's proposal of stabilizing our branch-1 for maintenance
releases, getting away from all the minors if we can. Do we have a quorum
of folks able and willing to do that work? Seems like it would center
around the 1.4 release.

If branch-1.1 retires in the next 2-6 months, are we happy with branch-1.2,
branch-1.3, or branch-1.4 carrying on the monthly cadence? Do we have a
strong need to continue 1.x once 2.x is out? Are we calling 1.2 the LTS
with quarterly patch releases, 1.3 aborted on arrival, and pushing folks
onto 2.x? Do we want to settle on quarterly or bi-annual minor releases and
only patch monthly or as necessary in between?

Thanks,
Nick

On Wed, Aug 9, 2017 at 8:00 AM, Mike Drob  wrote:

> One thing that we need to be super careful about after releasing 2.0 is
> that we don't accidentally introduce any incompatible changes. It's much
> harder to reason about forwards compatibility than backwards compatibility
> in my experience. So even though a hypothetical 1.5 would be released after
> 2.0, users would still have the expectation that a 1.5->2.0 upgrade would
> be smooth (unless we explicitly message that it isn't but that is a whole
> new set of problems).
>
> Also, to clarify some context here -- what is the difference between an LTS
> branch and a Stable branch? Don't they convey the same thing to users? As a
> relative newcomer, I feel like I missed an earlier conversation about this.
>
> Mike
>
> On Tue, Aug 8, 2017 at 10:45 PM, Phil Yang  wrote:
>
> > Another option is no 1.5/branch-1 any more. What new features we are
> going
> > to have in HBase 1.5 (if it will be released)? Backporting from branch-2
> to
> > branch-1 is not easy, so maybe we will not have any big feature in
> branch-1
> > after releasing 1.4. And if we release 1.5 after releasing 2.0, it may
> > confuse users. So IMO we can focus on branch-2 for new features.
> >
> > I think it will be good if we have fixed logic for EOL branches, for
> > example(just an example, can discuss):
> > 1:Release a final version and EOL 1.x after we think 1.x+1 is stable.
> > 2:Cut off new 1.x+2 branch after 1.x+1 is stable, don't cut too early.
> >
> > Then we will not need discussing each time for each branch EOL and we
> will
> > have a fixed number of maintaining branches.
> >
> > Thanks,
> > Phil
> >
> >
> > 2017-08-09 1:44 GMT+08:00 Andrew Purtell :
> >
> > > Well you are not wrong that branching was premature, it turns out. But
> > I'll
> > > roll with it...
> > >
> > >
> > > On Tue, Aug 8, 2017 at 10:43 AM, Zach York <
> zyork.contribut...@gmail.com
> > >
> > > wrote:
> > >
> > > > > I made branch-1.4 a few weeks ago only.
> > > >
> > > > Whoops, sorry for that! For some reason I thought I had seen it
> months
> > > ago.
> > > >
> > > > On Tue, Aug 8, 2017 at 10:40 AM, Andrew Purtell  >
> > > > wrote:
> > > >
> > > > > +1 from me on making 1.1 our LTS. Either 1.1 or 1.2 are
> candidates. I
> > > > think
> > > > > 1.1 has the edge because it lacks locking changes introduced into
> > 1.2,
> > > > just
> > > > > like 1.2 lacks locking changes introduced in 1.3 - the latter of
> > which
> > > > has
> > > > > had far reaching consequences, and the former not an insignificant
> > > change
> > > > > either.
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Aug 8, 2017 at 10:31 AM, Nick Dimiduk 
> > > > wrote:
> > > > >
> > > > > > On Tue, Aug 8, 2017 at 9:15 AM Mike Drob 
> wrote:
> > > > > >
> > > > > > > > The discussion also brought up the notion of an LTS release
> > line.
> > > > I'm
> > > > > > not
> > > > > > > > sure how this jives with the more fequent minors, but would
> > > require
> > > > > > some
> > > > > > > > branch that's so stable that an RM can effectively spin
> > releases
> > > > > blind.
> > > > > > >
> > > > > > > Seems to me like this branch would necessarily need to be very
> > > > > > > backport-light? Only the top of the highest priority issues
> would
> > > be
> > > > > > > backportable to it, no?
> > > > > >
> > > > > >
> > > > > > The LTS is as 1.1 is today -- bug fixes only. The difference here
> > is
> > > > we'd
> > > > > > "formally" recognize the LTS designation somehow, perhaps with a
> > > > symlink
> > > > > > marker as we do for the "stable" designation.
> > > > > >
> > > > > > On Tue, Aug 8, 2017 at 11:09 AM, Nick Dimiduk <
> ndimi...@apache.org
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Last time we DISCUSSed EOL of 1.1 was back in November. At
> that
> > > > > time, a
> > > > > > > > litany of issues were raised re: 1.2. Have those concerns
> been
> > > > > > addressed?
> > > > > > > > It seems to me that making this one the last release is too
> > > abrupt
> > > > to
> > > > > > > folks
> > > > > > > > tracking Apache. Would be

Delaying 1.1.13 for another month

2017-09-18 Thread Nick Dimiduk 
Heya folks,

There's slim commits to branch-1.1 over the last month. Looks like nothing
pressing by my eyes, so I'm going to let the branch simmer for another
month, let more changes accumulate. Will check back in with you in early
October.

Reply here if you have strong feeling to the contrary.

Kindly yours,
Nick

[jira] [Created] (HBASE-18845) TestReplicationSmallTests fails after HBASE-14004

2017-09-18 Thread Duo Zhang (JIRA) 
Duo Zhang created HBASE-18845:
-

 Summary: TestReplicationSmallTests fails after HBASE-14004
 Key: HBASE-18845
 URL: https://issues.apache.org/jira/browse/HBASE-18845
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 2.0.0-alpha-3, 3.0.0
Reporter: Duo Zhang
 Fix For: 3.0.0, 2.0.0-alpha-4


testEmptyWALRecovery and testVerifyRepJob



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-18844) Release hbase-2.0.0-alpha-4; Theme "Coprocessor API Cleanup"

2017-09-18 Thread stack (JIRA) 
stack created HBASE-18844:
-

 Summary: Release hbase-2.0.0-alpha-4; Theme "Coprocessor API 
Cleanup"
 Key: HBASE-18844
 URL: https://issues.apache.org/jira/browse/HBASE-18844
 Project: HBase
  Issue Type: Bug
Reporter: stack






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (HBASE-18767) Release hbase-2.0.0-alpha-3; Theme "Scrubbed API"

2017-09-18 Thread stack (JIRA) 

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

stack resolved HBASE-18767.
---
   Resolution: Fixed
 Assignee: stack
Fix Version/s: (was: 2.0.0-alpha-4)
   2.0.0-alpha-3

Release 2.0.0-alpha-3. 

> Release hbase-2.0.0-alpha-3; Theme "Scrubbed API"
> -
>
> Key: HBASE-18767
> URL: https://issues.apache.org/jira/browse/HBASE-18767
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-3
>
>
> From the dev mail thread: "Moving 2.0 forward", the theme is solidifying API. 
> I listed a bunch of API JIRAs to address. [~mdrob] nicely tagged them all w/ 
> the 2.0.0-alpha-3 fix version. This issue is for pushing out alpha-3.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-18843) Add DistCp support to incremental backup with bulk loading

2017-09-18 Thread Vladimir Rodionov (JIRA) 
Vladimir Rodionov created HBASE-18843:
-

 Summary: Add DistCp support to incremental backup with bulk loading
 Key: HBASE-18843
 URL: https://issues.apache.org/jira/browse/HBASE-18843
 Project: HBase
  Issue Type: Improvement
Reporter: Vladimir Rodionov
Assignee: Vladimir Rodionov






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (HBASE-14417) Incremental backup and bulk loading

2017-09-18 Thread Ted Yu (JIRA) 

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

Ted Yu resolved HBASE-14417.

Resolution: Fixed

> Incremental backup and bulk loading
> ---
>
> Key: HBASE-14417
> URL: https://issues.apache.org/jira/browse/HBASE-14417
> Project: HBase
>  Issue Type: New Feature
>Reporter: Vladimir Rodionov
>Assignee: Ted Yu
>Priority: Blocker
>  Labels: backup
> Fix For: 2.0.0
>
> Attachments: 14417-tbl-ext.v10.txt, 14417-tbl-ext.v11.txt, 
> 14417-tbl-ext.v14.txt, 14417-tbl-ext.v18.txt, 14417-tbl-ext.v19.txt, 
> 14417-tbl-ext.v20.txt, 14417-tbl-ext.v21.txt, 14417-tbl-ext.v22.txt, 
> 14417-tbl-ext.v23.txt, 14417-tbl-ext.v24.txt, 14417-tbl-ext.v9.txt, 
> 14417.v11.txt, 14417.v13.txt, 14417.v1.txt, 14417.v21.txt, 14417.v23.txt, 
> 14417.v24.txt, 14417.v25.txt, 14417.v2.txt, 14417.v6.txt
>
>
> Currently, incremental backup is based on WAL files. Bulk data loading 
> bypasses WALs for obvious reasons, breaking incremental backups. The only way 
> to continue backups after bulk loading is to create new full backup of a 
> table. This may not be feasible for customers who do bulk loading regularly 
> (say, every day).
> Here is the review board (out of date):
> https://reviews.apache.org/r/54258/
> In order not to miss the hfiles which are loaded into region directories in a 
> situation where postBulkLoadHFile() hook is not called (bulk load being 
> interrupted), we record hfile names thru preCommitStoreFile() hook.
> At time of incremental backup, we check the presence of such hfiles. If they 
> are present, they become part of the incremental backup image.
> Here is review board:
> https://reviews.apache.org/r/57790/
> Google doc for design:
> https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (HBASE-14417) Incremental backup and bulk loading

2017-09-18 Thread Vladimir Rodionov (JIRA) 

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

Vladimir Rodionov reopened HBASE-14417:
---
  Assignee: Vladimir Rodionov  (was: Ted Yu)

> Incremental backup and bulk loading
> ---
>
> Key: HBASE-14417
> URL: https://issues.apache.org/jira/browse/HBASE-14417
> Project: HBase
>  Issue Type: New Feature
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
>  Labels: backup
> Fix For: 2.0.0
>
> Attachments: 14417-tbl-ext.v10.txt, 14417-tbl-ext.v11.txt, 
> 14417-tbl-ext.v14.txt, 14417-tbl-ext.v18.txt, 14417-tbl-ext.v19.txt, 
> 14417-tbl-ext.v20.txt, 14417-tbl-ext.v21.txt, 14417-tbl-ext.v22.txt, 
> 14417-tbl-ext.v23.txt, 14417-tbl-ext.v24.txt, 14417-tbl-ext.v9.txt, 
> 14417.v11.txt, 14417.v13.txt, 14417.v1.txt, 14417.v21.txt, 14417.v23.txt, 
> 14417.v24.txt, 14417.v25.txt, 14417.v2.txt, 14417.v6.txt
>
>
> Currently, incremental backup is based on WAL files. Bulk data loading 
> bypasses WALs for obvious reasons, breaking incremental backups. The only way 
> to continue backups after bulk loading is to create new full backup of a 
> table. This may not be feasible for customers who do bulk loading regularly 
> (say, every day).
> Here is the review board (out of date):
> https://reviews.apache.org/r/54258/
> In order not to miss the hfiles which are loaded into region directories in a 
> situation where postBulkLoadHFile() hook is not called (bulk load being 
> interrupted), we record hfile names thru preCommitStoreFile() hook.
> At time of incremental backup, we check the presence of such hfiles. If they 
> are present, they become part of the incremental backup image.
> Here is review board:
> https://reviews.apache.org/r/57790/
> Google doc for design:
> https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-18842) The hbase shell clone_snaphost command returns bad error message

2017-09-18 Thread Thoralf Gutierrez (JIRA) 
Thoralf Gutierrez created HBASE-18842:
-

 Summary: The hbase shell clone_snaphost command returns bad error 
message
 Key: HBASE-18842
 URL: https://issues.apache.org/jira/browse/HBASE-18842
 Project: HBase
  Issue Type: Bug
Reporter: Thoralf Gutierrez
Priority: Minor


When you call the hbase shell clone_snapshot command with a target namespace 
that doesn't exist, you get an error message, but the variable used to identify 
the inexistent namespace is wrong:

{noformat}
hbase(main):001:0> clone_snapshot 'someSnapshotName', 
'someNamespaceName:someTableName'

ERROR: Unknown namespace someSnapshotName!

Create a new table by cloning the snapshot content.
There're no copies of data involved.
And writing on the newly created table will not influence the snapshot data.

Examples:
  hbase> clone_snapshot 'snapshotName', 'tableName'
  hbase> clone_snapshot 'snapshotName', 'namespace:tableName'
{noformat}

It should rather say:

{noformat}
ERROR: Unknown namespace someNamespaceName!
{noformat}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Helper tool / checklist to facilitate RC testing coverage?

2017-09-18 Thread Umesh Agashe 
I think this is a good idea. Having a list documented itself is big plus.
Explicitly listing Required/ Mandatory checks and Optional checks for
release type (e.g. alpha, beta etc) will help too.

On Mon, Sep 18, 2017 at 1:10 PM, Andrew Purtell  wrote:

> I also think it's fair to make allowances for folks who want to test the RC
> but might be short on personal time. So there should be a list of essential
> items (like sigs, sums, shas/tags) and then a list of optional items (ltt,
> pe, itbll, etc.)
>
> On Mon, Sep 18, 2017 at 12:52 PM, Stack  wrote:
>
> > On Mon, Sep 18, 2017 at 11:49 AM, Misty Stanley-Jones 
> > wrote:
> >
> > > I keep feeling like we need a checklist for all the different things
> that
> > > should be tested when people vote on a release candidate. Not everyone
> > > needs to do all the checks, but probably at least someone should be
> doing
> > > each of the following (and maybe things I am forgetting):
> > >
> > > - Binary .tar.gz and .zip extract
> > > - Source .tar.gz and .zip extract
> > > - All md5sums match
> > > - The source .tar.gz matches the hash on the Git repo
> > > - Everything is signed correctly
> > > - The source compiles into exactly the binary
> > > - The source compiles with both OpenJDK and Oracle JDK (?)
> > > - The binaries from the binary .tar.gz and .zip run as expected
> > > - The binaries built from the source .tar.gz and .zip run as expected
> > > - The standard tests all run and pass, with the exception of known
> > flakies
> > > - LTT and PE tools run and look good
> > >
> > >
> > > Would it be helpful to have some kind of dashboard where people could
> > "sign
> > > up" to test different things on that checklist, and maybe to require
> that
> > > all the checks have been done by at least someone before the RC can be
> > > released? Maybe it could be something silly like a Google Form, even.
> Or
> > a
> > > spreadsheet.
> > >
> > > I think it might also be less intimidating for newbies who have never
> > voted
> > > on an RC before (and we really really want as many people as possible
> to
> > > participate in the voting process).
> > >
> > > What do y'all think?
> > >
> > > Misty
> > >
> >
> >
> > Sounds great.
> >
> > St.Ack
> >
> > P.S.Here is a link to an old email that points at a LarsH doc. which
> cribs
> > from an old Dave Wang wiki page that tried to do similar:
> > http://search-hadoop.com/m/HBase/YGbb22RVtnt76g?subj=Re+Releases+tests+
> >
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [DISCUSS] Helper tool / checklist to facilitate RC testing coverage?

2017-09-18 Thread Mike Drob 
One thing that I've seen in successful other communities is that when folks
run the long running tests they also document the specifics of the
configuration that they used. Things like your java version, operating
system, EC2 instance type. Then this all gets fed into a table published
with the release notes.

I think it does a lot to give users confidence in the releases when they
can see that there has been testing on a variety of platforms with a
variety of settings. It's also a super rough way to catch performance
regressions since the release notes will contain that ITBLL ran for 24
hours with X entries on Y machines and that can be compared across versions.

Mike

On Mon, Sep 18, 2017 at 3:10 PM, Andrew Purtell  wrote:

> I also think it's fair to make allowances for folks who want to test the RC
> but might be short on personal time. So there should be a list of essential
> items (like sigs, sums, shas/tags) and then a list of optional items (ltt,
> pe, itbll, etc.)
>
> On Mon, Sep 18, 2017 at 12:52 PM, Stack  wrote:
>
> > On Mon, Sep 18, 2017 at 11:49 AM, Misty Stanley-Jones 
> > wrote:
> >
> > > I keep feeling like we need a checklist for all the different things
> that
> > > should be tested when people vote on a release candidate. Not everyone
> > > needs to do all the checks, but probably at least someone should be
> doing
> > > each of the following (and maybe things I am forgetting):
> > >
> > > - Binary .tar.gz and .zip extract
> > > - Source .tar.gz and .zip extract
> > > - All md5sums match
> > > - The source .tar.gz matches the hash on the Git repo
> > > - Everything is signed correctly
> > > - The source compiles into exactly the binary
> > > - The source compiles with both OpenJDK and Oracle JDK (?)
> > > - The binaries from the binary .tar.gz and .zip run as expected
> > > - The binaries built from the source .tar.gz and .zip run as expected
> > > - The standard tests all run and pass, with the exception of known
> > flakies
> > > - LTT and PE tools run and look good
> > >
> > >
> > > Would it be helpful to have some kind of dashboard where people could
> > "sign
> > > up" to test different things on that checklist, and maybe to require
> that
> > > all the checks have been done by at least someone before the RC can be
> > > released? Maybe it could be something silly like a Google Form, even.
> Or
> > a
> > > spreadsheet.
> > >
> > > I think it might also be less intimidating for newbies who have never
> > voted
> > > on an RC before (and we really really want as many people as possible
> to
> > > participate in the voting process).
> > >
> > > What do y'all think?
> > >
> > > Misty
> > >
> >
> >
> > Sounds great.
> >
> > St.Ack
> >
> > P.S.Here is a link to an old email that points at a LarsH doc. which
> cribs
> > from an old Dave Wang wiki page that tried to do similar:
> > http://search-hadoop.com/m/HBase/YGbb22RVtnt76g?subj=Re+Releases+tests+
> >
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [DISCUSS] Helper tool / checklist to facilitate RC testing coverage?

2017-09-18 Thread Andrew Purtell 
I also think it's fair to make allowances for folks who want to test the RC
but might be short on personal time. So there should be a list of essential
items (like sigs, sums, shas/tags) and then a list of optional items (ltt,
pe, itbll, etc.)

On Mon, Sep 18, 2017 at 12:52 PM, Stack  wrote:

> On Mon, Sep 18, 2017 at 11:49 AM, Misty Stanley-Jones 
> wrote:
>
> > I keep feeling like we need a checklist for all the different things that
> > should be tested when people vote on a release candidate. Not everyone
> > needs to do all the checks, but probably at least someone should be doing
> > each of the following (and maybe things I am forgetting):
> >
> > - Binary .tar.gz and .zip extract
> > - Source .tar.gz and .zip extract
> > - All md5sums match
> > - The source .tar.gz matches the hash on the Git repo
> > - Everything is signed correctly
> > - The source compiles into exactly the binary
> > - The source compiles with both OpenJDK and Oracle JDK (?)
> > - The binaries from the binary .tar.gz and .zip run as expected
> > - The binaries built from the source .tar.gz and .zip run as expected
> > - The standard tests all run and pass, with the exception of known
> flakies
> > - LTT and PE tools run and look good
> >
> >
> > Would it be helpful to have some kind of dashboard where people could
> "sign
> > up" to test different things on that checklist, and maybe to require that
> > all the checks have been done by at least someone before the RC can be
> > released? Maybe it could be something silly like a Google Form, even. Or
> a
> > spreadsheet.
> >
> > I think it might also be less intimidating for newbies who have never
> voted
> > on an RC before (and we really really want as many people as possible to
> > participate in the voting process).
> >
> > What do y'all think?
> >
> > Misty
> >
>
>
> Sounds great.
>
> St.Ack
>
> P.S.Here is a link to an old email that points at a LarsH doc. which cribs
> from an old Dave Wang wiki page that tried to do similar:
> http://search-hadoop.com/m/HBase/YGbb22RVtnt76g?subj=Re+Releases+tests+
>



-- 
Best regards,
Andrew

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

Re: [DISCUSS] Helper tool / checklist to facilitate RC testing coverage?

2017-09-18 Thread Stack 
On Mon, Sep 18, 2017 at 11:49 AM, Misty Stanley-Jones 
wrote:

> I keep feeling like we need a checklist for all the different things that
> should be tested when people vote on a release candidate. Not everyone
> needs to do all the checks, but probably at least someone should be doing
> each of the following (and maybe things I am forgetting):
>
> - Binary .tar.gz and .zip extract
> - Source .tar.gz and .zip extract
> - All md5sums match
> - The source .tar.gz matches the hash on the Git repo
> - Everything is signed correctly
> - The source compiles into exactly the binary
> - The source compiles with both OpenJDK and Oracle JDK (?)
> - The binaries from the binary .tar.gz and .zip run as expected
> - The binaries built from the source .tar.gz and .zip run as expected
> - The standard tests all run and pass, with the exception of known flakies
> - LTT and PE tools run and look good
>
>
> Would it be helpful to have some kind of dashboard where people could "sign
> up" to test different things on that checklist, and maybe to require that
> all the checks have been done by at least someone before the RC can be
> released? Maybe it could be something silly like a Google Form, even. Or a
> spreadsheet.
>
> I think it might also be less intimidating for newbies who have never voted
> on an RC before (and we really really want as many people as possible to
> participate in the voting process).
>
> What do y'all think?
>
> Misty
>


Sounds great.

St.Ack

P.S.Here is a link to an old email that points at a LarsH doc. which cribs
from an old Dave Wang wiki page that tried to do similar:
http://search-hadoop.com/m/HBase/YGbb22RVtnt76g?subj=Re+Releases+tests+

Re: [DISCUSS] Helper tool / checklist to facilitate RC testing coverage?

2017-09-18 Thread Dima Spivak 
Big +1. I opened HBASE-16559 to start working on this last year, but then
life happened.

-Dima

On Mon, Sep 18, 2017 at 11:53 AM, Ted Yu  wrote:

> bq. have some kind of dashboard where people could "sign up" to test
> different things on that checklist
>
> This makes sense.
> +1
>
>
> On Mon, Sep 18, 2017 at 11:49 AM, Misty Stanley-Jones 
> wrote:
>
> > I keep feeling like we need a checklist for all the different things that
> > should be tested when people vote on a release candidate. Not everyone
> > needs to do all the checks, but probably at least someone should be doing
> > each of the following (and maybe things I am forgetting):
> >
> > - Binary .tar.gz and .zip extract
> > - Source .tar.gz and .zip extract
> > - All md5sums match
> > - The source .tar.gz matches the hash on the Git repo
> > - Everything is signed correctly
> > - The source compiles into exactly the binary
> > - The source compiles with both OpenJDK and Oracle JDK (?)
> > - The binaries from the binary .tar.gz and .zip run as expected
> > - The binaries built from the source .tar.gz and .zip run as expected
> > - The standard tests all run and pass, with the exception of known
> flakies
> > - LTT and PE tools run and look good
> >
> >
> > Would it be helpful to have some kind of dashboard where people could
> "sign
> > up" to test different things on that checklist, and maybe to require that
> > all the checks have been done by at least someone before the RC can be
> > released? Maybe it could be something silly like a Google Form, even. Or
> a
> > spreadsheet.
> >
> > I think it might also be less intimidating for newbies who have never
> voted
> > on an RC before (and we really really want as many people as possible to
> > participate in the voting process).
> >
> > What do y'all think?
> >
> > Misty
> >
>

[ANNOUNCE] Apache HBase 2.0.0-alpha-3 is now available for download

2017-09-18 Thread Stack 
The HBase team is happy to announce the immediate availability of Apache
HBase
2.0.0-alpha-3.

Apache HBase is an open-source, distributed, versioned, non-relational
database. Apache HBase gives you low latency random access to billions of
rows with millions of columns atop non-specialized hardware. To learn more
about HBase, see https://hbase.apache.org/.

hbase-2.0.0-alpha-3 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.

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 dev-list "[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.

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.

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 [4].

We'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 let us know if there is anything you would
have us change or anything you see missing by mailing dev@hbase.apache.org
or by filing issues at https://issues.apache.org/jira/projects/HBASE/summary

We are planning one more alpha release before we move to beta (the above
mentioned alpha-4). Now is the time to catch the egregious and flag the
incompatibilities while we have time to bend. Once we move to beta, APIs
and feature-set will be fixed.

Download through an ASF mirror near you:

 https://www.apache.org/dyn/closer.lua/hbase/2.0.0-alpha-3

Checksums can be found here:


https://www.apache.org/dist/hbase/2.0.0-alpha-3/hbase-2.0.0-alpha3-bin.tar.gz.md5

https://www.apache.org/dist/hbase/2.0.0-alpha-3/hbase-2.0.0-alpha3-src.tar.gz.md5

Project member signature keys can be found at

https://www.apache.org/dist/hbase/KEYS

PGP signatures are here:


https://www.apache.org/dist/hbase/2.0.0-alpha-3/hbase-2.0.0-alpha3-src.tar.gz.asc

https://www.apache.org/dist/hbase/2.0.0-alpha-3/hbase-2.0.0-alpha3-bin.tar.gz.asc

For instructions on verifying ASF release downloads, please see

https://www.apache.org/dyn/closer.cgi#verify

Known issues are:

+ The LoadTestTool does not work (HBASE-18832).
+ MapReduce may fail for you (HBASE-18803 Mapreduce job get failed caused by
NoClassDefFoundError: org/apache/commons/lang3/ArrayUtils.)

Question, comments, and problems are always welcome at:
dev@hbase.apache.org.

Yours,
The HBase Dev Team

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/xHE7fF
5. https://issues.apache.org/jira/projects/HBASE/versions/12327188
6.
https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_ktczrlKHK8N4SZzs/

Re: [DISCUSS] Helper tool / checklist to facilitate RC testing coverage?

2017-09-18 Thread Ted Yu 
bq. have some kind of dashboard where people could "sign up" to test
different things on that checklist

This makes sense.
+1


On Mon, Sep 18, 2017 at 11:49 AM, Misty Stanley-Jones 
wrote:

> I keep feeling like we need a checklist for all the different things that
> should be tested when people vote on a release candidate. Not everyone
> needs to do all the checks, but probably at least someone should be doing
> each of the following (and maybe things I am forgetting):
>
> - Binary .tar.gz and .zip extract
> - Source .tar.gz and .zip extract
> - All md5sums match
> - The source .tar.gz matches the hash on the Git repo
> - Everything is signed correctly
> - The source compiles into exactly the binary
> - The source compiles with both OpenJDK and Oracle JDK (?)
> - The binaries from the binary .tar.gz and .zip run as expected
> - The binaries built from the source .tar.gz and .zip run as expected
> - The standard tests all run and pass, with the exception of known flakies
> - LTT and PE tools run and look good
>
>
> Would it be helpful to have some kind of dashboard where people could "sign
> up" to test different things on that checklist, and maybe to require that
> all the checks have been done by at least someone before the RC can be
> released? Maybe it could be something silly like a Google Form, even. Or a
> spreadsheet.
>
> I think it might also be less intimidating for newbies who have never voted
> on an RC before (and we really really want as many people as possible to
> participate in the voting process).
>
> What do y'all think?
>
> Misty
>

[jira] [Created] (HBASE-18840) Add functionality to refresh meta table at master startup

2017-09-18 Thread Zach York (JIRA) 
Zach York created HBASE-18840:
-

 Summary: Add functionality to refresh meta table at master startup
 Key: HBASE-18840
 URL: https://issues.apache.org/jira/browse/HBASE-18840
 Project: HBase
  Issue Type: Sub-task
Reporter: Zach York
Assignee: Zach York


If a HBase cluster’s hbase:meta table is deleted or a cluster is started with a 
new meta table, HBase needs the functionality to synchronize it’s metadata from 
Storage.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[DISCUSS] Helper tool / checklist to facilitate RC testing coverage?

2017-09-18 Thread Misty Stanley-Jones 
I keep feeling like we need a checklist for all the different things that
should be tested when people vote on a release candidate. Not everyone
needs to do all the checks, but probably at least someone should be doing
each of the following (and maybe things I am forgetting):

- Binary .tar.gz and .zip extract
- Source .tar.gz and .zip extract
- All md5sums match
- The source .tar.gz matches the hash on the Git repo
- Everything is signed correctly
- The source compiles into exactly the binary
- The source compiles with both OpenJDK and Oracle JDK (?)
- The binaries from the binary .tar.gz and .zip run as expected
- The binaries built from the source .tar.gz and .zip run as expected
- The standard tests all run and pass, with the exception of known flakies
- LTT and PE tools run and look good


Would it be helpful to have some kind of dashboard where people could "sign
up" to test different things on that checklist, and maybe to require that
all the checks have been done by at least someone before the RC can be
released? Maybe it could be something silly like a Google Form, even. Or a
spreadsheet.

I think it might also be less intimidating for newbies who have never voted
on an RC before (and we really really want as many people as possible to
participate in the voting process).

What do y'all think?

Misty

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

2017-09-18 Thread Stack 
With 4 binding +1s and 3 non-binding, the VOTE passes.

Thank you to all who voted, especially the non-PMCers. Them votes look
really pretty.

Let me push out alpha-3.

Alpha-4 with better scripted RM'ing and Coprocessor API cleanup coming
right up!

St.Ack



On Mon, Sep 18, 2017 at 9:31 AM, Josh Elser  wrote:

> +1 (binding)
>
> * Build from src
> * Can run pseudo-dist standalone with built software
> * XSums/Sigs OK
>
> - Josh
>
> On 9/15/17 2:03 PM, Stack wrote:
>
>> 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
>> 
>>
>>
>> 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/1WCsVlnHjJeKUcl7wHwqb4z9i
>> Eu_ktczrlKHK8N4SZzs/edit#heading=h.723jjn18p2jr
>> 2. Why CPs are Incompatible:
>> https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9i
>> Eu_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/1WCsVlnHjJeKUcl7wHwqb4z9i
>> Eu_ktczrlKHK8N4SZzs/
>>
>>

[jira] [Created] (HBASE-18839) Region#getRegionInfo should return Region instead of HRegion

2017-09-18 Thread Chia-Ping Tsai (JIRA) 
Chia-Ping Tsai created HBASE-18839:
--

 Summary: Region#getRegionInfo should return Region instead of 
HRegion
 Key: HBASE-18839
 URL: https://issues.apache.org/jira/browse/HBASE-18839
 Project: HBase
  Issue Type: Sub-task
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Introduce the limited private to filter

2017-09-18 Thread Dave Latham 
Speaking on behalf of one HBase deployment, we do rely on custom filters,
though have so far stayed away from more internal customizations such as
co-processors.  We've gotten the sense over the years that Filters were
fairly stable and seemed more reliable in that sense.  I'd be sad if a
change like this meant that more caution will need to be used in order to
rely on Filters.  I understand that some cleanup may need to happen (e.g.
HBASE-13346) but hope that we can still be conservative in breaking the
Filter apis.

On Sat, Sep 16, 2017 at 7:27 PM, Chia-Ping Tsai  wrote:

> hi stack
> I have filed https://issues.apache.org/jira/browse/HBASE-18811. FYI.
>
> On 2017-09-17 05:31, Stack  wrote:
> > It is an oversight that Filters are not annotated as (limited)private. We
> > are unable to guarantee them what public entails given their design is as
> > yet imperfect and that they are interpolated at points subject to change.
> >
> > +1 on taking them limited private in 2.0.0.
> >
> > Thanks for bringing this up Chia-Ping Tsai. Apt.
> >
> > St.Ack
> >
> >
> > On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai 
> wrote:
> >
> > > Hi, Folks!
> > >
> > > We have many powerful callback functions to help user to build amazing
> > > application/services. The most of functions are declared as
> > > IA.LimitedPrivate excluding the filters. As i see it, the
> IA.LimitedPrivate
> > > will make the improvement of filter more flexible. Also, we can
> introduce
> > > more server-side components to filters.
> > >
> > > https://issues.apache.org/jira/browse/HBASE-9529 had already left the
> > > TODO "add filter limited private level" on FilterBase. I feel it is
> time to
> > > discuss it again.
> > >
> > > Thanks,
> > > Chia-Ping Tsai
> > >
> > >
> >
>

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

2017-09-18 Thread Josh Elser 

+1 (binding)

* Build from src
* Can run pseudo-dist standalone with built software
* XSums/Sigs OK

- Josh

On 9/15/17 2:03 PM, Stack wrote:

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


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: [VOTE] First hbase-2.0.0-alpha-3 Release Candidate is available

2017-09-18 Thread Andrew Purtell 
+1

Sums and signatures are ok. That's as far as I got.

LTT is my go to test so normally if it fails I'd veto but this is an alpha
release. Also, several unit tests are failing, so I don't get a good build,
but it's an alpha release so I won't veto on that account either
(especially).


> (all of the above found via recursive diff between unpacking source
tarball and checkout of tag)

This is a good idea I'll have to remember for next time. 'mvn
apache-rat:check' doesn't catch these issues.


On Mon, Sep 18, 2017 at 9:04 AM, Stack  wrote:

> On Sun, Sep 17, 2017 at 9:50 PM, Sean Busbey  wrote:
>
> > +1
> >
> > good:
> >
> > * checksums are all good
> > * signatures are all good
> > * spot check of LICENSE / NOTICE looks okay (spat of "optional"
> > call-outs in NOTICE could be removed)
> > * source can build binary tarball that matches convenience
> > tarball posted.
> > * tag is signed and verifies as good
> >
> >
> > No good; will hold my nose for 'alpha'.
> >
> > * CHANGES.txt file hasn't been updated correctly. currently has details
> > for 0.93
> > * the source tarball contains binaries. this has our source tarball at
> > ~100MiB instead of ~18MiB.
> > * additional ways the source tarball does not match the source tag
> > *  * also a few dependency-reduced-pom.xml files included
> > *  * we don't have the .pylintrc file from our source
> > *  * also we have a spurious directory in hbase-server/src/main/site
> > *  * we don't have hbase-native-client directory, which is in source tag
> >
> > (all of the above found via recursive diff between unpacking source
> > tarball and checkout of tag)
> >
> >
> Nice list Sean. Thanks for holding nose. I should have done a clean before
> generating src tgz.
>
> St.Ack
>
>
>
>
> >
> >
> > On Fri, Sep 15, 2017 at 1:03 PM, Stack  wrote:
> > > 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
> > > 
> > >
> > > 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

[jira] [Resolved] (HBASE-18811) Introduce the limited private to filter

2017-09-18 Thread Chia-Ping Tsai (JIRA) 

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

Chia-Ping Tsai resolved HBASE-18811.

Resolution: Later

> Introduce the limited private to filter
> ---
>
> Key: HBASE-18811
> URL: https://issues.apache.org/jira/browse/HBASE-18811
> Project: HBase
>  Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18811.v0.patch
>
>
> We have many powerful callback functions to help user to build amazing 
> application/services. The most of functions are declared as IA.LimitedPrivate 
> excluding the filters. As i see it, the IA.LimitedPrivate will make the 
> improvement of filter more flexible. Also, we can introduce more server-side 
> components to filters. In conclusion, we should consider adding the limited 
> private level for filter.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-18838) shaded artifacts are incorrect when built against hadoop 3

2017-09-18 Thread Sean Busbey (JIRA) 
Sean Busbey created HBASE-18838:
---

 Summary: shaded artifacts are incorrect when built against hadoop 3
 Key: HBASE-18838
 URL: https://issues.apache.org/jira/browse/HBASE-18838
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 2.0.0-alpha-3
Reporter: Sean Busbey
Assignee: Sean Busbey
Priority: Critical
 Fix For: 2.0.0-alpha-4


Building master/branch-2 against the hadoop-3 profile results in 
check-invariants screaming about unrelocated dependencies. will list details in 
comment.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

2017-09-18 Thread Stack 
On Sun, Sep 17, 2017 at 9:50 PM, Sean Busbey  wrote:

> +1
>
> good:
>
> * checksums are all good
> * signatures are all good
> * spot check of LICENSE / NOTICE looks okay (spat of "optional"
> call-outs in NOTICE could be removed)
> * source can build binary tarball that matches convenience
> tarball posted.
> * tag is signed and verifies as good
>
>
> No good; will hold my nose for 'alpha'.
>
> * CHANGES.txt file hasn't been updated correctly. currently has details
> for 0.93
> * the source tarball contains binaries. this has our source tarball at
> ~100MiB instead of ~18MiB.
> * additional ways the source tarball does not match the source tag
> *  * also a few dependency-reduced-pom.xml files included
> *  * we don't have the .pylintrc file from our source
> *  * also we have a spurious directory in hbase-server/src/main/site
> *  * we don't have hbase-native-client directory, which is in source tag
>
> (all of the above found via recursive diff between unpacking source
> tarball and checkout of tag)
>
>
Nice list Sean. Thanks for holding nose. I should have done a clean before
generating src tgz.

St.Ack




>
>
> On Fri, Sep 15, 2017 at 1:03 PM, Stack  wrote:
> > 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
> > 
> >
> > 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: [VOTE] First hbase-2.0.0-alpha-3 Release Candidate is available

2017-09-18 Thread Stack 
Thanks all for the wonderful votes. I need another PMC'er for the vote to
pass...
Thanks,
M

On Fri, Sep 15, 2017 at 11:03 AM, Stack  wrote:

> 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
> 
>
> I tagged the RC as 2.0.0-alpha-3RC0.2 (a5c8461ca87d6324f16ffd126b7651
> 46fdd5315a)
>
> 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/
>

[jira] [Created] (HBASE-18837) HTableMultiplexer behavior during regions split

2017-09-18 Thread chausson (JIRA) 
chausson created HBASE-18837:


 Summary: HTableMultiplexer behavior during regions split
 Key: HBASE-18837
 URL: https://issues.apache.org/jira/browse/HBASE-18837
 Project: HBase
  Issue Type: Improvement
  Components: Client
Affects Versions: 1.1.2
Reporter: chausson
Priority: Minor


HTableMultiplexer class mentions following in the javadoc : "If any queue is 
full, the HTableMultiplexer starts to drop the Put requests for that particular 
queue."

This could be improved by replacing following code in 
HTableMultiplexer.resubmitFailedPut() method :

try {
succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut, 
retryCount);
} finally {
FlushWorker.this.getRetryInQueue().decrementAndGet();
if (!succ) {
FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
}
}

With : 
try {
succ = FlushWorker.this.getMultiplexer().put(tableName, failedPut, 
retryCount);
if (!succ) {
if (!resubmitFailedPut(ps, oldLoc)) {

FlushWorker.this.getTotalFailedPutCount().incrementAndGet();
}
}
} finally {
FlushWorker.this.getRetryInQueue().decrementAndGet();
}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

2017-09-18 Thread 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/
>

[jira] [Created] (HBASE-18836) fix shaded jar for javax.el

2017-09-18 Thread Sean Busbey (JIRA) 
Sean Busbey created HBASE-18836:
---

 Summary: fix shaded jar for javax.el
 Key: HBASE-18836
 URL: https://issues.apache.org/jira/browse/HBASE-18836
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 2.0.0-alpha-4
Reporter: Sean Busbey
Assignee: Sean Busbey
Priority: Blocker
 Fix For: 2.0.0-alpha-4


jar contents include a non-relocated dependency again.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

2017-09-18 Thread ashish singhi 
+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 


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/

[jira] [Created] (HBASE-18835) The return type of ExtendedCell#deepClone should be ExtendedCell rather than Cell

2017-09-18 Thread Chia-Ping Tsai (JIRA) 
Chia-Ping Tsai created HBASE-18835:
--

 Summary: The return type of ExtendedCell#deepClone should be 
ExtendedCell rather than Cell
 Key: HBASE-18835
 URL: https://issues.apache.org/jira/browse/HBASE-18835
 Project: HBase
  Issue Type: Task
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)