hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [DISCUSS] Separate Git Repository for HBCK2
Date Wed, 25 Jul 2018 18:18:45 GMT
Yes, and in that vein also VerifyReplication and tools of that nature.


On Wed, Jul 25, 2018 at 11:11 AM Josh Elser <elserj@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 <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
> >>
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message