busbey commented on a change in pull request #22: HBASE-22951 [HBCK2] hbase 
hbck throws IOE "No FileSystem for scheme: …
URL: 
https://github.com/apache/hbase-operator-tools/pull/22#discussion_r320520884
 
 

 ##########
 File path: hbase-hbck2/README.md
 ##########
 @@ -19,39 +19,51 @@
 # Apache HBase HBCK2 Tool
 
 HBCK2 is the successor to 
[hbck](https://hbase.apache.org/book.html#hbck.in.depth),
-the hbase-1.x fixup tool (A.K.A _hbck1_). Use it in place of _hbck1_ making 
repairs against hbase-2.x installs.
+the hbase-1.x fixup tool (A.K.A _hbck1_). Use it in place of _hbck1_ making 
repairs
+against hbase-2.x installs.
 
 ## _hbck1_
 The _hbck_ tool that ships with hbase-1.x (A.K.A _hbck1_) should not be run 
against an
 hbase-2.x cluster. It may do damage. While _hbck1_ is still bundled inside 
hbase-2.x
--- to minimize surprise (it has a fat pointer to _HBCK2_ at the head of its 
help
-output) -- it's write-facility (`-fix`) has been removed. It can report on the 
state
-of an hbase-2.x cluster but its assessments are likely inaccurate since it 
does not
-understand the internal workings of an hbase-2.x.
-
-_HBCK2_ does much less than _hbck1_ because many of the class of problems
-_hbck1_ addressed are either no longer issues in hbase-2.x, or we've made
-(or will make) a dedicated tool to do what _hbck1_ used incorporate. _HBCK2_ 
also
-works in a manner that differs from how _hbck1_ operated, asking the HBase
-Master to do its bidding, rather than replicate functionality outside of the
-Master inside the _hbck1_ tool.
+-- to minimize surprise -- it's write-facility (`-fix`) has been removed. It 
can report
+on the state of an hbase-2.x cluster but its assessments are likely inaccurate 
since it
+does not understand the internal workings of an hbase-2.x.
+
+_HBCK2_ differs from _hbck1_ philosophically. Each run performs a discrete 
task rather than
+presume the tool can  repair 'all problems'. It is more of the vein of
+[`plumbing` than 
`porecelain`](https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain).
 
 ## Building _HBCK2_
 
 Run:
 ```
 mvn install
 ```
-The built _HBCK2_ fat jar will be in the `target` sub-directory.
+The built _HBCK2_ jar will be in the `target` sub-directory.
 
 ## Running _HBCK2_
-`org.apache.hbase.HBCK2` is the name of the _HBCK2_ main class. After building
-_HBCK2_ to generate the _HBCK2_ jar file, running the below will dump out the 
_HBCK2_ usage:
-
+The _HBCK2_ jar does not include dependencies; it is not built as a 'fat' jar.
+Dependencies must be `provided`. Building, adjusting the target hbase version 
in the
+top-level pom to match your deploy will make for the smoothest operation (See
+the parent pom.xml `hbase-operator-tools` for the
+[hbase.version to 
set](https://github.com/apache/hbase-operator-tools/blob/master/pom.xml#L126)).
+Where this can get interesting is when _HBCK2_ is in advance of your hbase
+deploy such that your hbase does not support all APIs in current _HBCK2_. Where
+_HBCK2_ does not have needed server-side support it should fail gracefully.
 
 Review comment:
   This should specify that it means at runtime. When the server API is missing 
at build time we just fail to build.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to