On Mon, Oct 22, 2018 at 10:21 AM Josh Elser <[email protected]> wrote:
> Orthogonal question: you codifying the "damage" you're doing? > > No. What you thinking? Writing unit tests that launch substantial clusters that get damaged in various ways? We'd then use tools to fix and confirm wholesomeness? If so, tooling is currently inadequate or absent as is understanding of the various failure types and then what the subsequent fixes should be (For general travails, see [1]). > I remember trying to debug hbck1 unit test failures (and it was a pain). > Coming back with fresh/high-level test scenarios sounds like a great way > to keep quality on hbck2 up. > > Agree. hbck2 has some tests of its basic functionality but I at least have done no work beyond that. S 1. https://docs.google.com/document/d/1Y0HIo5yRGXi7nl-JWc69JtxB87fYE-jXe8nBe7HWKe0/edit#heading=h.8e0m4iclfn0g > On 10/19/18 1:32 PM, Stack wrote: > > * Lots of progress on an hbck2. It has some basic utility (see below) > that > > has been useful to me at least hacking on a test cluster I've been doing > > damage too this last week or so. It exits with complaint if run against > an > > hbase that doesn't have support for hbck2 ops (i.e. < 2.0.3 or < 2.1.0) > and > > it is itself versioned. I'll work on a bit of doc and our Sean is working > > on making it easy to find and run over in HBASE-21215 > > <https://issues.apache.org/jira/browse/HBASE-21215>. We could cut a > 1.0.0RC > > inside the next week or so I'd say. >
