[
https://issues.apache.org/jira/browse/HBASE-21072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16594581#comment-16594581
]
Hudson commented on HBASE-21072:
--------------------------------
Results for branch master
[build #461 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/461/]: (x)
*{color:red}-1 overall{color}*
----
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/461//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/461//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/461//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Block out HBCK1 in hbase2
> -------------------------
>
> Key: HBASE-21072
> URL: https://issues.apache.org/jira/browse/HBASE-21072
> Project: HBase
> Issue Type: Sub-task
> Components: hbck
> Affects Versions: 2.0.1
> Reporter: stack
> Assignee: stack
> Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.2
>
> Attachments: HBASE-21072-addendum.patch,
> HBASE-21072.branch-2.0.001.patch, HBASE-21072.branch-2.0.002.patch,
> HBASE-21072.branch-2.0.003.patch, HBASE-21072.branch-2.0.003.patch
>
>
> [~busbey] left a note in the parent issue that I only just read which has a
> prescription for how we might block hbck1 from running against an hbase-2.x
> (hbck1 could damage a hbase-2....Its disabled in hbase-2 but an errant hbck1
> from an hbase-1.x install might run).
> Here is quote from parent issue:
> {code}
> I was idly thinking about how to stop HBase v1 HBCK. Thanks to HBASE-11405,
> we know that all HBase 1.y.z hbck instances should refuse to run if there's a
> lock file at '/hbase/hbase-hbck.lock' (given defaults). How about HBase v2
> places that file permanently in place and replace the contents (usually just
> an IP address) with a note about how you must not run HBase v1 HBCK against
> the cluster?
> {code}
> There is also the below:
> {code}
> We could pick another location for locking on HBase version 2 and start
> building in a version check of some kind?
> {code}
> ... to which I'd answer, lets see. hbck2 is a different beast. It asks the
> master to do stuff. It doesn't do it itself, as hbck1 did. So no need of a
> lock/version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
