(-cc user as this I'm getting purely into code development topics)
First off, thanks for working on an hbck2, Umesh!
I like the idea of having a separate repository for tracking HBCK and
the flexibility it gives us for making releases at a cadence of our
choosing.
There are two worries that come to mind immediately:
* How often does HBCK make decisions on how to implement a correction
based on some known functionality (e.g. a bug) in a specific version(s)
of HBase. Concretely, would HBCK need to make corrections to an HBase
installation that are specific to a subset of HBase 2.x.y versions that
may not be valid for other 2.x.y versions?
* How often does HBCK need to re-use methods and constants from code in
hbase-common, hbase-server, etc?
- Related: Is it a goal to firm up API stability around this shared
code or are you planning to just copy needed code to the HBCK2 repo? I
think you are saying that this *is* a goal -- could/should we introduce
some new level of InterfaceAudience to assert that we don't
inadvertently break HBCK2?
Thanks!
On 7/19/18 5:09 PM, Umesh Agashe wrote:
Hi,
I've had the opportunity to talk about HBCK2 with a few of you. One of the
suggestions is to to have a separate git repository for HBCK2. Lets discuss
about it.
In the past when bugs were found in hbck, there is no easy way to release
patched version of just hbck (without patching HBase). If HBCK2 has a
separate git repo, HBCK2 versions will not be tightly related to HBase
versions. Fixing and releasing hbck2, may not require patching HBase.
Though tight coupling will be somewhat loosened, HBCK2 will still depend on
HBase APIs/ code. Caution will be required going forward regarding
compatibility.
What you all think?
Thanks,
Umesh
JIRA: https://issues.apache.org/jira/browse/HBASE-19121.
Doc:
https://docs.google.com/document/d/1NxSFu4TKQ6lY-9J5qsCcJb9kZOnkfX66KMYsiVxBy0Y/edit?usp=sharing
