hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [DISCUSS] Separate Git Repository for HBCK2
Date Wed, 25 Jul 2018 18:11:08 GMT
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 <apurtell@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 <stack@duboce.net> wrote:
>>> On Thu, Jul 19, 2018 at 2:09 PM Umesh Agashe
>> <uagashe@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

View raw message