Yes, and in that vein also VerifyReplication and tools of that nature.
On Wed, Jul 25, 2018 at 11:11 AM Josh Elser <els...@apache.org> wrote: > Thanks, Umesh. Seems like you're saying it's not a problem now, but > you're not sure if it would become a problem. Regardless of that, it's a > goal to not be version-specific (and thus, we can have generic hbck-v1 > and hbck-v2 tools). LMK if I misread, please :) > > One more thought, it would be nice to name this repository as > "operator-tools" or similar (instead of hbck). A separate repo on its > own release cadence is a nice vehicle for random sorts of recovery, > slice-and-dice, one-off tools. I think HBCK is one example of > administrator/operator tooling we provide (certainly, the most used), > but we have the capacity to provide more than just that. > > On 7/24/18 5:55 PM, Umesh Agashe wrote: > > Thanks Stack, Josh and Andrew for your suggestions and concerns. > > > > I share Stack's suggestions. This would be similar to hbase-thirdparty. > The > > new repo could be hbase-hbck/hbase-hbck2. As this tool will be used by > > hbase users/ developers, hbase JIRA can be used for hbck issues. > > > > bq. How often does HBCK need to re-use methods and constants from code > > in hbase-common, hbase-server, etc? > > bq. Is it a goal to firm up API stability around this shared code. > > > > bq. If we do this can we also move out hbck version 1? > > > > As HBCK2 tool will be freshly written, we can try to achieve this goal. I > > think its great idea to move hbck1 to new repo as well. Though I think > its > > more involved with hbck1 as the existing code already uses what it can > from > > hbase-common and hbase-server etc. modules. > > > > bq. 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? > > > > I see if this happens too often, compatibility metrics will be > complicated. > > > > Thanks, > > Umesh > > > > > > On Tue, Jul 24, 2018 at 10:27 AM Andrew Purtell <apurt...@apache.org> > wrote: > > > >> If we do this can we also move out hbck version 1? It would be really > weird > >> in my opinion to have v2 in a separate repo but v1 shipping with the 1.x > >> releases. That would be a source of understandable confusion. > >> > >> I believe our compatibility guidelines allow us to upgrade interface > >> annotations from private to LP or Public and from LP to Public. These > are > >> not changes that impact source or binary compatibility. They only change > >> the promises we make going forward about their stability. I believe we > can > >> allow these in new minors, so we could potentially move hbck out in a > >> 1.5.0. > >> > >> > >> On Mon, Jul 23, 2018 at 4:46 PM Stack <st...@duboce.net> wrote: > >> > >>> On Thu, Jul 19, 2018 at 2:09 PM Umesh Agashe > >> <uaga...@cloudera.com.invalid > >>>> > >>> 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? > >>>> > >>>> > >>> I think this the way to go. > >>> > >>> We'd make a new hbase-hbck2 repo as we did for hbase-thirdparty? > >>> > >>> We'd use the hbase JIRA for hbase-hbck2 issues? > >>> > >>> We'd make hbase-hbck2 releases on occasion that the PMC voted on? > >>> > >>> Sounds great! > >>> St.Ack > >>> > >>> Thanks, > >>>> Umesh > >>>> > >>>> JIRA: https://issues.apache.org/jira/browse/HBASE-19121. > >>>> Doc: > >>>> > >>>> > >>> > >> > https://docs.google.com/document/d/1NxSFu4TKQ6lY-9J5qsCcJb9kZOnkfX66KMYsiVxBy0Y/edit?usp=sharing > >>>> > >>> > >> > >> > >> -- > >> Best regards, > >> Andrew > >> > >> Words like orphans lost among the crosstalk, meaning torn from truth's > >> decrepit hands > >> - A23, Crosstalk > >> > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
