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
>>
>
|