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

[Andrew Purtell]

+1

Checked sums and signatures: ok
Built from source: ok (7u80)
RAT check passed: ok (7u80)
Unit tests pass: ok (8u102)
Loaded 1M rows with LTT: ok (8u102), all keys verified, latencies in the
ballpark, nothing unusual in the logs


On Fri, Mar 10, 2017 at 2:31 PM, Sean Busbey  wrote:

> The first release candidate for HBase 1.2.5 is available for download at:
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/
>
> Maven artifacts are also available in a staging repository at:
>
> https://repository.apache.org/content/repositories/orgapachehbase-1164/
>
> 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.5RC0, which currently points
> to commit ref
>
> d7b05f79dee10e0ada614765bb354b93d615a157
>
> The detailed source and binary compatibility report vs 1.2.4 has been
> published for your review, at:
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.5RC0/
> 1.2.4_1.2.5RC0_compat_report.html
>
> Note that this report calls out the issue discussed in HBASE-17725.
>
> HBase 1.2.5 is the fifth 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 over 50 bug fixes since 1.2.4.
> Critical fixes include:
>
> * HBASE-17069 RegionServer writes invalid META entries for split
> daughters in some circumstances
> * HBASE-17044 Fix merge failed before creating merged region leaves
> meta inconsistent
> * HBASE-17206 FSHLog may roll a new writer successfully with unflushed
> entries
> * HBASE-16765 New SteppingRegionSplitPolicy, avoid too aggressive
> spread of regions for small tables.
>
>
> The full list of fixes included in this release is available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12338339=12310753
>
> 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.5.
>
> The VOTE will remain open for atleast 72 hours. Given sufficient votes
> I would like to close it on March 17th, 2017.
>
> thanks!
>



-- 
Best regards,

   - Andy

If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)

Successful: hbase.apache.org HTML Checker

[Apache Jenkins Server]

Successful

If successful, the HTML and link-checking report for http://hbase.apache.org is 
available at 
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/86/artifact/link_report/index.html.

If failed, see 
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/86/console.

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

[Ted Yu]

As of 6:06pm PST, I still saw these branches on
https://github.com/apache/hbase/

Maybe there is some delay.

Thanks Andrew.

On Mon, Mar 13, 2017 at 5:59 PM, Andrew Purtell  wrote:

> That's because this was pushed with a different name. It's gone now.
>
> apurtell@onyx:~/src/hbase$ git branch -a | grep 14123
>   remotes/origin/14123
> apurtell@onyx:~/src/hbase$ git push origin :14123
> Username for 'https://git-wip-us.apache.org': apurtell
> Password for 'https://apurt...@git-wip-us.apache.org':
> To https://git-wip-us.apache.org/repos/asf/hbase.git
>  - [deleted] 14123
>
>
> On Mon, Mar 13, 2017 at 4:13 PM, Ted Yu  wrote:
>
> > I tried to delete the HBASE-14123 branch using commands I found on
> > http://stackoverflow.com/questions/2003505/how-to-
> > delete-a-git-branch-both-locally-and-remotely
> >
> > Not sure if there is lag on github side:
> >
> > $ git push origin :origin/HBASE-14123
> > error: unable to delete 'origin/HBASE-14123': remote ref does not exist
> > error: failed to push some refs to '
> > https://git-wip-us.apache.org/repos/asf/hbase.git'
> >
> > FYI
> >
> > On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar  wrote:
> >
> > > I think there is some misconception of using the term "blockers" for
> > > referring to those jiras. My understanding is that those three jiras
> are
> > > blockers for the backup functionality to be more mature and more
> usable.
> > > But they are not release blockers. Let's say we merged the code in, and
> > for
> > > some reason those did not get addressed in time. We can still do the
> 2.0
> > > release without having to wait for the commits. We can instead mark the
> > > "backup" feature as experimental with known issues and go on with the
> > > release. In that sense they are not real release blockers.
> > >
> > > We are proposing the merge at this time because of the above that
> > > maintaining this in a branch is becoming extremely costly and not
> > > productive for the HBase community. Realistically, we cannot have the
> > > luxury of having to wait another couple of months and doing yet another
> > > giant round of reviews because the code base is a moving target.
> > >
> > > Enis
> > >
> > > On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das 
> > wrote:
> > >
> > > > Vlad, on the first point, I think what Stack is saying is that
> creating
> > > > the new branch (as Ted did) ignores the feedback incorporated thus
> far
> > in
> > > > the iterations of the mega-patch. That's a wrong way to go.
> > > > On the separation into a backup module, again, that was reverted to
> > ease
> > > > reviews of the mega-patch, and was noted as work to be done later. I
> > > think
> > > > Stack just wants to make the list of remaining work more complete by
> > > citing
> > > > that as pending work.
> > > > 
> > > > From: Vladimir Rodionov 
> > > > Sent: Monday, March 13, 2017 3:09 PM
> > > > To: dev@hbase.apache.org
> > > > Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote
> closing
> > > > 3/11/2017
> > > >
> > > > >>  It ignores the feedback
> > > >
> > > > If I "ignore" feedback, I put my comment - why? I am always  open for
> > > > further discussions. If reviewer does not insist on a particular
> > request
> > > -
> > > > it will be dropped. I think it is fair.
> > > >
> > > > >> he list is incomplete because a bunch of
> > > > >> follow-ons came of the review cycle (including moving
> backup/restore
> > > out
> > > > of
> > > > >> core to live in its own module).
> > > >
> > > > For those who were not following our lengthy conversation on a review
> > > > board, separation of a backup code into a separate module has been
> > > > done last year, but has been reverted back by request of a reviewer.
> > > >
> > > >
> > > > -Vladimir
> > > >
> > > > On Mon, Mar 13, 2017 at 2:23 PM, Stack  wrote:
> > > >
> > > > > On Fri, Mar 10, 2017 at 9:09 PM, Stack  wrote:
> > > > >
> > > > > > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu 
> > wrote:
> > > > > >
> > > > > >> HBASE-14123 branch has been created, with Vlad's mega patch v61.
> > > > > >>
> > > > > >
> > > > > > The patch put up for VOTE here was done on a branch. The call to
> > > merge
> > > > > > seems to have been premature given the many cycles of review and
> > test
> > > > > that
> > > > > > happened subsequent (The cycles burned a bunch of dev resource).
> > > > > >
> > > > > > The patch as is is now in a state where it is too big for our
> > infra;
> > > rb
> > > > > > and JIRA are creaking under the size and # of iterations.
> > > > > >
> > > > > > Adding finish of new JIRAs to this merge implies a new round of
> > > review
> > > > > and
> > > > > > test of an already massive patch. Who is going to do this work?
> > > > > >
> > > > > > Going back to a new branch seems wrong route to take.
> > > > > >

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

[Andrew Purtell]

That's because this was pushed with a different name. It's gone now.

apurtell@onyx:~/src/hbase$ git branch -a | grep 14123
  remotes/origin/14123
apurtell@onyx:~/src/hbase$ git push origin :14123
Username for 'https://git-wip-us.apache.org': apurtell
Password for 'https://apurt...@git-wip-us.apache.org':
To https://git-wip-us.apache.org/repos/asf/hbase.git
 - [deleted] 14123


On Mon, Mar 13, 2017 at 4:13 PM, Ted Yu  wrote:

> I tried to delete the HBASE-14123 branch using commands I found on
> http://stackoverflow.com/questions/2003505/how-to-
> delete-a-git-branch-both-locally-and-remotely
>
> Not sure if there is lag on github side:
>
> $ git push origin :origin/HBASE-14123
> error: unable to delete 'origin/HBASE-14123': remote ref does not exist
> error: failed to push some refs to '
> https://git-wip-us.apache.org/repos/asf/hbase.git'
>
> FYI
>
> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar  wrote:
>
> > I think there is some misconception of using the term "blockers" for
> > referring to those jiras. My understanding is that those three jiras are
> > blockers for the backup functionality to be more mature and more usable.
> > But they are not release blockers. Let's say we merged the code in, and
> for
> > some reason those did not get addressed in time. We can still do the 2.0
> > release without having to wait for the commits. We can instead mark the
> > "backup" feature as experimental with known issues and go on with the
> > release. In that sense they are not real release blockers.
> >
> > We are proposing the merge at this time because of the above that
> > maintaining this in a branch is becoming extremely costly and not
> > productive for the HBase community. Realistically, we cannot have the
> > luxury of having to wait another couple of months and doing yet another
> > giant round of reviews because the code base is a moving target.
> >
> > Enis
> >
> > On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das 
> wrote:
> >
> > > Vlad, on the first point, I think what Stack is saying is that creating
> > > the new branch (as Ted did) ignores the feedback incorporated thus far
> in
> > > the iterations of the mega-patch. That's a wrong way to go.
> > > On the separation into a backup module, again, that was reverted to
> ease
> > > reviews of the mega-patch, and was noted as work to be done later. I
> > think
> > > Stack just wants to make the list of remaining work more complete by
> > citing
> > > that as pending work.
> > > 
> > > From: Vladimir Rodionov 
> > > Sent: Monday, March 13, 2017 3:09 PM
> > > To: dev@hbase.apache.org
> > > Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing
> > > 3/11/2017
> > >
> > > >>  It ignores the feedback
> > >
> > > If I "ignore" feedback, I put my comment - why? I am always  open for
> > > further discussions. If reviewer does not insist on a particular
> request
> > -
> > > it will be dropped. I think it is fair.
> > >
> > > >> he list is incomplete because a bunch of
> > > >> follow-ons came of the review cycle (including moving backup/restore
> > out
> > > of
> > > >> core to live in its own module).
> > >
> > > For those who were not following our lengthy conversation on a review
> > > board, separation of a backup code into a separate module has been
> > > done last year, but has been reverted back by request of a reviewer.
> > >
> > >
> > > -Vladimir
> > >
> > > On Mon, Mar 13, 2017 at 2:23 PM, Stack  wrote:
> > >
> > > > On Fri, Mar 10, 2017 at 9:09 PM, Stack  wrote:
> > > >
> > > > > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu 
> wrote:
> > > > >
> > > > >> HBASE-14123 branch has been created, with Vlad's mega patch v61.
> > > > >>
> > > > >
> > > > > The patch put up for VOTE here was done on a branch. The call to
> > merge
> > > > > seems to have been premature given the many cycles of review and
> test
> > > > that
> > > > > happened subsequent (The cycles burned a bunch of dev resource).
> > > > >
> > > > > The patch as is is now in a state where it is too big for our
> infra;
> > rb
> > > > > and JIRA are creaking under the size and # of iterations.
> > > > >
> > > > > Adding finish of new JIRAs to this merge implies a new round of
> > review
> > > > and
> > > > > test of an already massive patch. Who is going to do this work?
> > > > >
> > > > > Going back to a new branch seems wrong route to take.
> > > > >
> > > > > St.Ack
> > > > >
> > > > >
> > > > >
> > > > To be more explicit, this patch was developed on a branch and then a
> > > bunch
> > > > of dev resources were burned getting it into a state where it could
> be
> > > > merged to master. Going back to a branch to bulk up the merge so it
> > > > includes more JIRAs than the many it already incorporates is the
> wrong
> > > > direction for us to be headed in. It ignores the feedback given 

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

[Andrew Purtell]

I don't like that issues were identified as "blockers" but now there is an
attempt to walk that back.

I don't like that development of this feature has lingered for a long time
in this unfinished state when this work could have been done by now, now
that we are trying to get a 2.0 out the door. Because this is a volunteer
project I cannot make any demand that it should be done, but I can
certainly look at the current state and be nonplussed. This will be yet
another half finished thing in 2.0 when this merge happens. Promises to
finish the unfinished work are nice but not currency. Commits are currency.
I hope at least the fault tolerance changes can be completed and committed
before we spin a 2.0 RC, and without causing a 2.0 release to slip further.

Also, marking something experimental should be done on the merits of that
evaluation, not simply to justify dropping unfinished work into a release
branch.

I will change my vote to -0.


On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar  wrote:

> I think there is some misconception of using the term "blockers" for
> referring to those jiras. My understanding is that those three jiras are
> blockers for the backup functionality to be more mature and more usable.
> But they are not release blockers. Let's say we merged the code in, and for
> some reason those did not get addressed in time. We can still do the 2.0
> release without having to wait for the commits. We can instead mark the
> "backup" feature as experimental with known issues and go on with the
> release. In that sense they are not real release blockers.
>
> We are proposing the merge at this time because of the above that
> maintaining this in a branch is becoming extremely costly and not
> productive for the HBase community. Realistically, we cannot have the
> luxury of having to wait another couple of months and doing yet another
> giant round of reviews because the code base is a moving target.
>
> Enis
>
> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das  wrote:
>
> > Vlad, on the first point, I think what Stack is saying is that creating
> > the new branch (as Ted did) ignores the feedback incorporated thus far in
> > the iterations of the mega-patch. That's a wrong way to go.
> > On the separation into a backup module, again, that was reverted to ease
> > reviews of the mega-patch, and was noted as work to be done later. I
> think
> > Stack just wants to make the list of remaining work more complete by
> citing
> > that as pending work.
> > 
> > From: Vladimir Rodionov 
> > Sent: Monday, March 13, 2017 3:09 PM
> > To: dev@hbase.apache.org
> > Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing
> > 3/11/2017
> >
> > >>  It ignores the feedback
> >
> > If I "ignore" feedback, I put my comment - why? I am always  open for
> > further discussions. If reviewer does not insist on a particular request
> -
> > it will be dropped. I think it is fair.
> >
> > >> he list is incomplete because a bunch of
> > >> follow-ons came of the review cycle (including moving backup/restore
> out
> > of
> > >> core to live in its own module).
> >
> > For those who were not following our lengthy conversation on a review
> > board, separation of a backup code into a separate module has been
> > done last year, but has been reverted back by request of a reviewer.
> >
> >
> > -Vladimir
> >
> > On Mon, Mar 13, 2017 at 2:23 PM, Stack  wrote:
> >
> > > On Fri, Mar 10, 2017 at 9:09 PM, Stack  wrote:
> > >
> > > > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu  wrote:
> > > >
> > > >> HBASE-14123 branch has been created, with Vlad's mega patch v61.
> > > >>
> > > >
> > > > The patch put up for VOTE here was done on a branch. The call to
> merge
> > > > seems to have been premature given the many cycles of review and test
> > > that
> > > > happened subsequent (The cycles burned a bunch of dev resource).
> > > >
> > > > The patch as is is now in a state where it is too big for our infra;
> rb
> > > > and JIRA are creaking under the size and # of iterations.
> > > >
> > > > Adding finish of new JIRAs to this merge implies a new round of
> review
> > > and
> > > > test of an already massive patch. Who is going to do this work?
> > > >
> > > > Going back to a new branch seems wrong route to take.
> > > >
> > > > St.Ack
> > > >
> > > >
> > > >
> > > To be more explicit, this patch was developed on a branch and then a
> > bunch
> > > of dev resources were burned getting it into a state where it could be
> > > merged to master. Going back to a branch to bulk up the merge so it
> > > includes more JIRAs than the many it already incorporates is the wrong
> > > direction for us to be headed in. It ignores the feedback given and the
> > > work done by Vladimir slimming down an already over-broad scope. It is
> > also
> > > predicated on abundant review and testing 

[jira] [Created] (HBASE-17780) BoundedByteBufferPool "At capacity" messages are not actionable

[Andrew Purtell (JIRA)]

Andrew Purtell created HBASE-17780:
--

 Summary: BoundedByteBufferPool "At capacity" messages are not 
actionable
 Key: HBASE-17780
 URL: https://issues.apache.org/jira/browse/HBASE-17780
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Fix For: 1.31, 2.0.0, 1.4.0


This comment in BoundedByteBufferPool talks about "At capacity ..." warnings 
from this class that may appear in logs when under load:

{code}
 * If a ByteBuffer is bigger than the configured threshold, we will just let 
the ByteBuffer go
 * rather than add it to the pool. If more ByteBuffers than the configured 
maximum instances,
 * we will not add the passed ByteBuffer to the pool; we will just drop it
 * (we will log a WARN in this case that we are at capacity).
{code}

First, dropping buffers when the pool is full is obviously an expected and 
normal condition. Second, there is nothing actionable about that warning. Might 
be useful for developers, perhaps. Drop it to DEBUG. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

[Ted Yu]

I tried to delete the HBASE-14123 branch using commands I found on
http://stackoverflow.com/questions/2003505/how-to-delete-a-git-branch-both-locally-and-remotely

Not sure if there is lag on github side:

$ git push origin :origin/HBASE-14123
error: unable to delete 'origin/HBASE-14123': remote ref does not exist
error: failed to push some refs to '
https://git-wip-us.apache.org/repos/asf/hbase.git'

FYI

On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar  wrote:

> I think there is some misconception of using the term "blockers" for
> referring to those jiras. My understanding is that those three jiras are
> blockers for the backup functionality to be more mature and more usable.
> But they are not release blockers. Let's say we merged the code in, and for
> some reason those did not get addressed in time. We can still do the 2.0
> release without having to wait for the commits. We can instead mark the
> "backup" feature as experimental with known issues and go on with the
> release. In that sense they are not real release blockers.
>
> We are proposing the merge at this time because of the above that
> maintaining this in a branch is becoming extremely costly and not
> productive for the HBase community. Realistically, we cannot have the
> luxury of having to wait another couple of months and doing yet another
> giant round of reviews because the code base is a moving target.
>
> Enis
>
> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das  wrote:
>
> > Vlad, on the first point, I think what Stack is saying is that creating
> > the new branch (as Ted did) ignores the feedback incorporated thus far in
> > the iterations of the mega-patch. That's a wrong way to go.
> > On the separation into a backup module, again, that was reverted to ease
> > reviews of the mega-patch, and was noted as work to be done later. I
> think
> > Stack just wants to make the list of remaining work more complete by
> citing
> > that as pending work.
> > 
> > From: Vladimir Rodionov 
> > Sent: Monday, March 13, 2017 3:09 PM
> > To: dev@hbase.apache.org
> > Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing
> > 3/11/2017
> >
> > >>  It ignores the feedback
> >
> > If I "ignore" feedback, I put my comment - why? I am always  open for
> > further discussions. If reviewer does not insist on a particular request
> -
> > it will be dropped. I think it is fair.
> >
> > >> he list is incomplete because a bunch of
> > >> follow-ons came of the review cycle (including moving backup/restore
> out
> > of
> > >> core to live in its own module).
> >
> > For those who were not following our lengthy conversation on a review
> > board, separation of a backup code into a separate module has been
> > done last year, but has been reverted back by request of a reviewer.
> >
> >
> > -Vladimir
> >
> > On Mon, Mar 13, 2017 at 2:23 PM, Stack  wrote:
> >
> > > On Fri, Mar 10, 2017 at 9:09 PM, Stack  wrote:
> > >
> > > > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu  wrote:
> > > >
> > > >> HBASE-14123 branch has been created, with Vlad's mega patch v61.
> > > >>
> > > >
> > > > The patch put up for VOTE here was done on a branch. The call to
> merge
> > > > seems to have been premature given the many cycles of review and test
> > > that
> > > > happened subsequent (The cycles burned a bunch of dev resource).
> > > >
> > > > The patch as is is now in a state where it is too big for our infra;
> rb
> > > > and JIRA are creaking under the size and # of iterations.
> > > >
> > > > Adding finish of new JIRAs to this merge implies a new round of
> review
> > > and
> > > > test of an already massive patch. Who is going to do this work?
> > > >
> > > > Going back to a new branch seems wrong route to take.
> > > >
> > > > St.Ack
> > > >
> > > >
> > > >
> > > To be more explicit, this patch was developed on a branch and then a
> > bunch
> > > of dev resources were burned getting it into a state where it could be
> > > merged to master. Going back to a branch to bulk up the merge so it
> > > includes more JIRAs than the many it already incorporates is the wrong
> > > direction for us to be headed in. It ignores the feedback given and the
> > > work done by Vladimir slimming down an already over-broad scope. It is
> > also
> > > predicated on abundant review and testing resource being on tap to
> cycle
> > on
> > > a feature that is useful, but non-core.
> > >
> > > The patch is ready for merge IMO. Geoffrey makes a nice list of what is
> > > still to do though IIRC, the list is incomplete because a bunch of
> > > follow-ons came of the review cycle (including moving backup/restore
> out
> > of
> > > core to live in its own module).
> > >
> > > The patch needs three votes to merge. I am not against merge but I am
> not
> > > voting for the patch because I do have any more time to spend on this
> > > 

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

[Enis Söztutar]

I think there is some misconception of using the term "blockers" for
referring to those jiras. My understanding is that those three jiras are
blockers for the backup functionality to be more mature and more usable.
But they are not release blockers. Let's say we merged the code in, and for
some reason those did not get addressed in time. We can still do the 2.0
release without having to wait for the commits. We can instead mark the
"backup" feature as experimental with known issues and go on with the
release. In that sense they are not real release blockers.

We are proposing the merge at this time because of the above that
maintaining this in a branch is becoming extremely costly and not
productive for the HBase community. Realistically, we cannot have the
luxury of having to wait another couple of months and doing yet another
giant round of reviews because the code base is a moving target.

Enis

On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das  wrote:

> Vlad, on the first point, I think what Stack is saying is that creating
> the new branch (as Ted did) ignores the feedback incorporated thus far in
> the iterations of the mega-patch. That's a wrong way to go.
> On the separation into a backup module, again, that was reverted to ease
> reviews of the mega-patch, and was noted as work to be done later. I think
> Stack just wants to make the list of remaining work more complete by citing
> that as pending work.
> 
> From: Vladimir Rodionov 
> Sent: Monday, March 13, 2017 3:09 PM
> To: dev@hbase.apache.org
> Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing
> 3/11/2017
>
> >>  It ignores the feedback
>
> If I "ignore" feedback, I put my comment - why? I am always  open for
> further discussions. If reviewer does not insist on a particular request -
> it will be dropped. I think it is fair.
>
> >> he list is incomplete because a bunch of
> >> follow-ons came of the review cycle (including moving backup/restore out
> of
> >> core to live in its own module).
>
> For those who were not following our lengthy conversation on a review
> board, separation of a backup code into a separate module has been
> done last year, but has been reverted back by request of a reviewer.
>
>
> -Vladimir
>
> On Mon, Mar 13, 2017 at 2:23 PM, Stack  wrote:
>
> > On Fri, Mar 10, 2017 at 9:09 PM, Stack  wrote:
> >
> > > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu  wrote:
> > >
> > >> HBASE-14123 branch has been created, with Vlad's mega patch v61.
> > >>
> > >
> > > The patch put up for VOTE here was done on a branch. The call to merge
> > > seems to have been premature given the many cycles of review and test
> > that
> > > happened subsequent (The cycles burned a bunch of dev resource).
> > >
> > > The patch as is is now in a state where it is too big for our infra; rb
> > > and JIRA are creaking under the size and # of iterations.
> > >
> > > Adding finish of new JIRAs to this merge implies a new round of review
> > and
> > > test of an already massive patch. Who is going to do this work?
> > >
> > > Going back to a new branch seems wrong route to take.
> > >
> > > St.Ack
> > >
> > >
> > >
> > To be more explicit, this patch was developed on a branch and then a
> bunch
> > of dev resources were burned getting it into a state where it could be
> > merged to master. Going back to a branch to bulk up the merge so it
> > includes more JIRAs than the many it already incorporates is the wrong
> > direction for us to be headed in. It ignores the feedback given and the
> > work done by Vladimir slimming down an already over-broad scope. It is
> also
> > predicated on abundant review and testing resource being on tap to cycle
> on
> > a feature that is useful, but non-core.
> >
> > The patch is ready for merge IMO. Geoffrey makes a nice list of what is
> > still to do though IIRC, the list is incomplete because a bunch of
> > follow-ons came of the review cycle (including moving backup/restore out
> of
> > core to live in its own module).
> >
> > The patch needs three votes to merge. I am not against merge but I am not
> > voting for the patch because I do have any more time to spend on this
> > non-core feature and feel that a vote will have me assume a
> responsibility
> > I will not shirk.
> >
> > S
> >
> >
> >
> > >
> > >
> > >
> > >> FYI
> > >>
> > >> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu  wrote:
> > >>
> > >> > Thanks for the feedback, Andrew.
> > >> >
> > >> > How about the following plan:
> > >> >
> > >> > create branch HBASE-14123 off of master with mega patch v61 as the
> > first
> > >> > commit (reviewed by Stack and Enis)
> > >> > Vlad and I continue development (the 3 blockers) based on
> HBASE-14123
> > >> >  branch
> > >> > when all of the blockers get +1 and merged into HBASE-14123 branch,
> we
> > >> > propose to community for merging into 

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

[Devaraj Das]

Vlad, on the first point, I think what Stack is saying is that creating the new 
branch (as Ted did) ignores the feedback incorporated thus far in the 
iterations of the mega-patch. That's a wrong way to go.
On the separation into a backup module, again, that was reverted to ease 
reviews of the mega-patch, and was noted as work to be done later. I think 
Stack just wants to make the list of remaining work more complete by citing 
that as pending work.

From: Vladimir Rodionov 
Sent: Monday, March 13, 2017 3:09 PM
To: dev@hbase.apache.org
Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

>>  It ignores the feedback

If I "ignore" feedback, I put my comment - why? I am always  open for
further discussions. If reviewer does not insist on a particular request -
it will be dropped. I think it is fair.

>> he list is incomplete because a bunch of
>> follow-ons came of the review cycle (including moving backup/restore out
of
>> core to live in its own module).

For those who were not following our lengthy conversation on a review
board, separation of a backup code into a separate module has been
done last year, but has been reverted back by request of a reviewer.


-Vladimir

On Mon, Mar 13, 2017 at 2:23 PM, Stack  wrote:

> On Fri, Mar 10, 2017 at 9:09 PM, Stack  wrote:
>
> > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu  wrote:
> >
> >> HBASE-14123 branch has been created, with Vlad's mega patch v61.
> >>
> >
> > The patch put up for VOTE here was done on a branch. The call to merge
> > seems to have been premature given the many cycles of review and test
> that
> > happened subsequent (The cycles burned a bunch of dev resource).
> >
> > The patch as is is now in a state where it is too big for our infra; rb
> > and JIRA are creaking under the size and # of iterations.
> >
> > Adding finish of new JIRAs to this merge implies a new round of review
> and
> > test of an already massive patch. Who is going to do this work?
> >
> > Going back to a new branch seems wrong route to take.
> >
> > St.Ack
> >
> >
> >
> To be more explicit, this patch was developed on a branch and then a bunch
> of dev resources were burned getting it into a state where it could be
> merged to master. Going back to a branch to bulk up the merge so it
> includes more JIRAs than the many it already incorporates is the wrong
> direction for us to be headed in. It ignores the feedback given and the
> work done by Vladimir slimming down an already over-broad scope. It is also
> predicated on abundant review and testing resource being on tap to cycle on
> a feature that is useful, but non-core.
>
> The patch is ready for merge IMO. Geoffrey makes a nice list of what is
> still to do though IIRC, the list is incomplete because a bunch of
> follow-ons came of the review cycle (including moving backup/restore out of
> core to live in its own module).
>
> The patch needs three votes to merge. I am not against merge but I am not
> voting for the patch because I do have any more time to spend on this
> non-core feature and feel that a vote will have me assume a responsibility
> I will not shirk.
>
> S
>
>
>
> >
> >
> >
> >> FYI
> >>
> >> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu  wrote:
> >>
> >> > Thanks for the feedback, Andrew.
> >> >
> >> > How about the following plan:
> >> >
> >> > create branch HBASE-14123 off of master with mega patch v61 as the
> first
> >> > commit (reviewed by Stack and Enis)
> >> > Vlad and I continue development (the 3 blockers) based on HBASE-14123
> >> >  branch
> >> > when all of the blockers get +1 and merged into HBASE-14123 branch, we
> >> > propose to community for merging into branch-2 (master branch, if
> >> branch-2
> >> > doesn't materialize for whatever reason) again
> >> >
> >> > Cheers
> >> >
> >> >
> >> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell 
> >> > wrote:
> >> >
> >> >> Thanks for the offer but I like that you were honest about compiling
> a
> >> >> list
> >> >> of issues that you thought were blockers for release. Since this
> >> proposal
> >> >> is a merge into 2.0, and we are trying to release 2.0, I am -1 on
> this
> >> >> merge until those blockers are addressed.
> >> >>
> >> >> I had a look at the list.
> >> >>
> >> >> I think the documentation issue is important but not actually a
> >> blocker.
> >> >> That may be a controversial opinion, but documentation can be
> >> back-filled
> >> >> worst case. So take HBASE-17133 off the list.
> >> >>
> >> >> Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227.
> >> They
> >> >> all have patches attached to the respective JIRAs so completing this
> >> work
> >> >> won't be onerous. Get these committed and I will lift my -1. The
> others
> >> >> who
> >> >> voted +1 on this thread surely can help with that.
> >> >>
> >> >> Thanks.
> >> >>
> >> >>
> 

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

[Vladimir Rodionov]

>>  It ignores the feedback

If I "ignore" feedback, I put my comment - why? I am always  open for
further discussions. If reviewer does not insist on a particular request -
it will be dropped. I think it is fair.

>> he list is incomplete because a bunch of
>> follow-ons came of the review cycle (including moving backup/restore out
of
>> core to live in its own module).

For those who were not following our lengthy conversation on a review
board, separation of a backup code into a separate module has been
done last year, but has been reverted back by request of a reviewer.


-Vladimir

On Mon, Mar 13, 2017 at 2:23 PM, Stack  wrote:

> On Fri, Mar 10, 2017 at 9:09 PM, Stack  wrote:
>
> > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu  wrote:
> >
> >> HBASE-14123 branch has been created, with Vlad's mega patch v61.
> >>
> >
> > The patch put up for VOTE here was done on a branch. The call to merge
> > seems to have been premature given the many cycles of review and test
> that
> > happened subsequent (The cycles burned a bunch of dev resource).
> >
> > The patch as is is now in a state where it is too big for our infra; rb
> > and JIRA are creaking under the size and # of iterations.
> >
> > Adding finish of new JIRAs to this merge implies a new round of review
> and
> > test of an already massive patch. Who is going to do this work?
> >
> > Going back to a new branch seems wrong route to take.
> >
> > St.Ack
> >
> >
> >
> To be more explicit, this patch was developed on a branch and then a bunch
> of dev resources were burned getting it into a state where it could be
> merged to master. Going back to a branch to bulk up the merge so it
> includes more JIRAs than the many it already incorporates is the wrong
> direction for us to be headed in. It ignores the feedback given and the
> work done by Vladimir slimming down an already over-broad scope. It is also
> predicated on abundant review and testing resource being on tap to cycle on
> a feature that is useful, but non-core.
>
> The patch is ready for merge IMO. Geoffrey makes a nice list of what is
> still to do though IIRC, the list is incomplete because a bunch of
> follow-ons came of the review cycle (including moving backup/restore out of
> core to live in its own module).
>
> The patch needs three votes to merge. I am not against merge but I am not
> voting for the patch because I do have any more time to spend on this
> non-core feature and feel that a vote will have me assume a responsibility
> I will not shirk.
>
> S
>
>
>
> >
> >
> >
> >> FYI
> >>
> >> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu  wrote:
> >>
> >> > Thanks for the feedback, Andrew.
> >> >
> >> > How about the following plan:
> >> >
> >> > create branch HBASE-14123 off of master with mega patch v61 as the
> first
> >> > commit (reviewed by Stack and Enis)
> >> > Vlad and I continue development (the 3 blockers) based on HBASE-14123
> >> >  branch
> >> > when all of the blockers get +1 and merged into HBASE-14123 branch, we
> >> > propose to community for merging into branch-2 (master branch, if
> >> branch-2
> >> > doesn't materialize for whatever reason) again
> >> >
> >> > Cheers
> >> >
> >> >
> >> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell 
> >> > wrote:
> >> >
> >> >> Thanks for the offer but I like that you were honest about compiling
> a
> >> >> list
> >> >> of issues that you thought were blockers for release. Since this
> >> proposal
> >> >> is a merge into 2.0, and we are trying to release 2.0, I am -1 on
> this
> >> >> merge until those blockers are addressed.
> >> >>
> >> >> I had a look at the list.
> >> >>
> >> >> I think the documentation issue is important but not actually a
> >> blocker.
> >> >> That may be a controversial opinion, but documentation can be
> >> back-filled
> >> >> worst case. So take HBASE-17133 off the list.
> >> >>
> >> >> Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227.
> >> They
> >> >> all have patches attached to the respective JIRAs so completing this
> >> work
> >> >> won't be onerous. Get these committed and I will lift my -1. The
> others
> >> >> who
> >> >> voted +1 on this thread surely can help with that.
> >> >>
> >> >> Thanks.
> >> >>
> >> >>
> >> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
> >> >> vladrodio...@gmail.com>
> >> >> wrote:
> >> >>
> >> >> > No problem I will downgrade Blockers to Majors if it scares you,
> >> Andrew
> >> >> 
> >> >> >
> >> >> > Sent from my iPhone
> >> >> >
> >> >> > > On Mar 10, 2017, at 1:52 PM, Andrew Purtell  >
> >> >> wrote:
> >> >> > >
> >> >> > > ​I know the merge of this feature has lagged substantially. I
> think
> >> >> that
> >> >> > is
> >> >> > > regrettable but on another thread we are lamenting that 2.0 is
> >> already
> >> >> > > late. Unless I misunderstand, this is a proposal to merge
> something
> >> >> with
> >> >> > > known blockers into 

Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017

[Stack]

On Fri, Mar 10, 2017 at 9:09 PM, Stack  wrote:

> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu  wrote:
>
>> HBASE-14123 branch has been created, with Vlad's mega patch v61.
>>
>
> The patch put up for VOTE here was done on a branch. The call to merge
> seems to have been premature given the many cycles of review and test that
> happened subsequent (The cycles burned a bunch of dev resource).
>
> The patch as is is now in a state where it is too big for our infra; rb
> and JIRA are creaking under the size and # of iterations.
>
> Adding finish of new JIRAs to this merge implies a new round of review and
> test of an already massive patch. Who is going to do this work?
>
> Going back to a new branch seems wrong route to take.
>
> St.Ack
>
>
>
To be more explicit, this patch was developed on a branch and then a bunch
of dev resources were burned getting it into a state where it could be
merged to master. Going back to a branch to bulk up the merge so it
includes more JIRAs than the many it already incorporates is the wrong
direction for us to be headed in. It ignores the feedback given and the
work done by Vladimir slimming down an already over-broad scope. It is also
predicated on abundant review and testing resource being on tap to cycle on
a feature that is useful, but non-core.

The patch is ready for merge IMO. Geoffrey makes a nice list of what is
still to do though IIRC, the list is incomplete because a bunch of
follow-ons came of the review cycle (including moving backup/restore out of
core to live in its own module).

The patch needs three votes to merge. I am not against merge but I am not
voting for the patch because I do have any more time to spend on this
non-core feature and feel that a vote will have me assume a responsibility
I will not shirk.

S



>
>
>
>> FYI
>>
>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu  wrote:
>>
>> > Thanks for the feedback, Andrew.
>> >
>> > How about the following plan:
>> >
>> > create branch HBASE-14123 off of master with mega patch v61 as the first
>> > commit (reviewed by Stack and Enis)
>> > Vlad and I continue development (the 3 blockers) based on HBASE-14123
>> >  branch
>> > when all of the blockers get +1 and merged into HBASE-14123 branch, we
>> > propose to community for merging into branch-2 (master branch, if
>> branch-2
>> > doesn't materialize for whatever reason) again
>> >
>> > Cheers
>> >
>> >
>> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell 
>> > wrote:
>> >
>> >> Thanks for the offer but I like that you were honest about compiling a
>> >> list
>> >> of issues that you thought were blockers for release. Since this
>> proposal
>> >> is a merge into 2.0, and we are trying to release 2.0, I am -1 on this
>> >> merge until those blockers are addressed.
>> >>
>> >> I had a look at the list.
>> >>
>> >> I think the documentation issue is important but not actually a
>> blocker.
>> >> That may be a controversial opinion, but documentation can be
>> back-filled
>> >> worst case. So take HBASE-17133 off the list.
>> >>
>> >> Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227.
>> They
>> >> all have patches attached to the respective JIRAs so completing this
>> work
>> >> won't be onerous. Get these committed and I will lift my -1. The others
>> >> who
>> >> voted +1 on this thread surely can help with that.
>> >>
>> >> Thanks.
>> >>
>> >>
>> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
>> >> vladrodio...@gmail.com>
>> >> wrote:
>> >>
>> >> > No problem I will downgrade Blockers to Majors if it scares you,
>> Andrew
>> >> 
>> >> >
>> >> > Sent from my iPhone
>> >> >
>> >> > > On Mar 10, 2017, at 1:52 PM, Andrew Purtell 
>> >> wrote:
>> >> > >
>> >> > > ​I know the merge of this feature has lagged substantially. I think
>> >> that
>> >> > is
>> >> > > regrettable but on another thread we are lamenting that 2.0 is
>> already
>> >> > > late. Unless I misunderstand, this is a proposal to merge something
>> >> with
>> >> > > known blockers into trunk before we branch it for 2.0 which will
>> >> > > effectively prevent that release because these blockers will be
>> >> there. I
>> >> > am
>> >> > > inclined to veto. Probably we should not propose branch merges into
>> >> code
>> >> > we
>> >> > > are trying to get out the door with known blockers. Why not do that
>> >> work
>> >> > > first? It seems an obvious question. Perhaps I am missing
>> something.
>> >> > >
>> >> > > If we can branch for 2.0 now and then merge this, and not into the
>> 2.0
>> >> > > branch, I would vote +1 for branch merge even with known blockers
>> >> > pending.
>> >> > > ​
>> >> > >
>> >> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
>> >> > vladrodio...@gmail.com>
>> >> > > wrote:
>> >> > >
>> >> > >> They are not blockers for merge - only for 2.0. GA
>> >> > >> As I said already the feature is usable right now
>> >> > >> We would like to continue 

[jira] [Resolved] (HBASE-17466) [C++] Test cleanup

[Enis Soztutar (JIRA)]

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

Enis Soztutar resolved HBASE-17466.
---
   Resolution: Fixed
Fix Version/s: HBASE-14850

Pushed this to the branch. 

> [C++] Test cleanup
> --
>
> Key: HBASE-17466
> URL: https://issues.apache.org/jira/browse/HBASE-17466
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: HBASE-14850
>
> Attachments: hbase-17466_v1.patch
>
>
> The tests takes too long due to sleep and starting / stopping the cluster. We 
> can do some speed up. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (HBASE-17771) [C++] Classes required for implementation of BatchCallerBuilder

[Enis Soztutar (JIRA)]

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

Enis Soztutar reopened HBASE-17771:
---

Accidentally resolved this. Reopening. 

> [C++] Classes required for implementation of BatchCallerBuilder
> ---
>
> Key: HBASE-17771
> URL: https://issues.apache.org/jira/browse/HBASE-17771
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Fix For: HBASE-14850
>
> Attachments: HBASE-17771.HBASE-14850.v1.patch
>
>
> Separating depedencies of BatchCallerBuilder.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (HBASE-17771) [C++] Classes required for implementation of BatchCallerBuilder

[Enis Soztutar (JIRA)]

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

Enis Soztutar resolved HBASE-17771.
---
   Resolution: Fixed
Fix Version/s: HBASE-14850

> [C++] Classes required for implementation of BatchCallerBuilder
> ---
>
> Key: HBASE-17771
> URL: https://issues.apache.org/jira/browse/HBASE-17771
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Fix For: HBASE-14850
>
> Attachments: HBASE-17771.HBASE-14850.v1.patch
>
>
> Separating depedencies of BatchCallerBuilder.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/514/artifact/website.patch.zip
 | funzip > fee67bcf1432cd16720fb97a0135bd67b0d2b064.patch
  git fetch
  git checkout -b asf-site-fee67bcf1432cd16720fb97a0135bd67b0d2b064 
origin/asf-site
  git am --whitespace=fix fee67bcf1432cd16720fb97a0135bd67b0d2b064.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-fee67bcf1432cd16720fb97a0135bd67b0d2b064 branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-fee67bcf1432cd16720fb97a0135bd67b0d2b064:asf-site
  git checkout asf-site
  git branch -D asf-site-fee67bcf1432cd16720fb97a0135bd67b0d2b064

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/514/console

[jira] [Created] (HBASE-17779) disable_table_replication returns misleading message and does not turn off repliaton

[Janos Gub (JIRA)]

Janos Gub created HBASE-17779:
-

 Summary: disable_table_replication returns misleading message and 
does not turn off repliaton
 Key: HBASE-17779
 URL: https://issues.apache.org/jira/browse/HBASE-17779
 Project: HBase
  Issue Type: Bug
Reporter: Janos Gub
Assignee: Janos Gub


Currently HBaseAdmin#isTableRepEnabled() returns false if ANY of the columns 
families is not replicated.

Because of this if you have a table where replication is partially enabled, 
calling disable_table_replication will not have any effect, but will report 
that replication for a given table is disabled.

Workaround is enabling table replication before disabling. 

As a solution quoted from HBASE-17460:
Admin#disableTableReplication() returns nothing and isTableRepEnabled() returns 
boolean. For master branch, we can let isTableRepEnabled() return enum 
(partially disabled, disabled, etc) This way, Admin#disableTableReplication() 
can return meaningful value to the user.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-17778) Remove the testing code in the AsyncRequestFutureImpl

[Chia-Ping Tsai (JIRA)]

Chia-Ping Tsai created HBASE-17778:
--

 Summary: Remove the testing code in the AsyncRequestFutureImpl
 Key: HBASE-17778
 URL: https://issues.apache.org/jira/browse/HBASE-17778
 Project: HBase
  Issue Type: Improvement
Affects Versions: 2.0.0, 1.4.0
Reporter: Chia-Ping Tsai
Priority: Trivial


HBASE-16224 left some testing code in the AsyncRequestFutureImpl. It iterates 
all mutations in order to get the data size. The cost is directly proportional 
to the size of batch. We should remove it. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)