[jira] [Created] (HBASE-17782) Introduce new configuration to decide reference type used in IdReadWriteLock
Yu Li created HBASE-17782: - Summary: Introduce new configuration to decide reference type used in IdReadWriteLock Key: HBASE-17782 URL: https://issues.apache.org/jira/browse/HBASE-17782 Project: HBase Issue Type: Task Affects Versions: 2.0 Reporter: Yu Li Assignee: Yu Li As per discussed in HBASE-17747, we need to make it configurable to decide whether to use weak or soft reference for {{IdReadWriteLock}}, with soft reference by default. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17781) TestAcidGuarantees
Anup Halarnkar created HBASE-17781: -- Summary: TestAcidGuarantees Key: HBASE-17781 URL: https://issues.apache.org/jira/browse/HBASE-17781 Project: HBase Issue Type: Bug Components: integration tests Affects Versions: 2.0.0 Environment: OS: Ubuntu 14.04 Arch: x86_64 uname -a = Linux xx-xx 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Reporter: Anup Halarnkar Fix For: 2.0.0 After applying patch HBASE-17723, the test "TestSimpleRpcScheduler" passes but, the below test fails. Results : Tests in error: TestAcidGuarantees.testGetAtomicity:418->runTestAtomicity:315->runTestAtomicity:324->runTestAtomicity:388 » Runtime TestAcidGuarantees.testMobGetAtomicity:435->runTestAtomicity:388 » Runtime Def... Tests run: 1774, Failures: 0, Errors: 2, Skipped: 6 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Re: [VOTE] First release candidate for HBase 1.2.5 is available
+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&projectId=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
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
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. > > > > > > > > > > > > St.Ack > > > > > > > > > > > > > > > > > > > > > > > To be more explicit, this patch was developed on a branch and then > a > > > > bunch > > > > > of
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
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 and > the > > > > work done by Vladimir slimming down an already over-broad scope. It > is > > > also > > > > predicated on abundant review and
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
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 resource being on tap to > cycle > > on > > > a feature that is useful, but non-core. > > > > > > The patch is ready for merg
[jira] [Created] (HBASE-17780) BoundedByteBufferPool "At capacity" messages are not actionable
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
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 > > > non-core feature and feel that a vote will have me assume a > > responsibility > > > I will not shirk. > > > > > > S > > > > >
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
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 branch-2 (master branch, if > > >> branch-2 > > >> > doesn't materialize for whatever reason) again > > >> > > > >> > Cheers > > >>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
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. > >> >> > >> >> > >> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov < > >> >> vladrodio...@gmail.com> > >> >> wrote: > >> >> > >> >> >
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. > >> >> > >> >> > >> >> 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
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
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 working on master and we would like to >> see >> >> a >> >> > >> commitment from community >> >> > >> >>
[jira] [Resolved] (HBASE-17466) [C++] Test cleanup
[ 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
[ 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
[ 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
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 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)