This sounds fine to me. More like "operator tooling" than "new
feature" and we're more lax on that stuff.
On Wed, Sep 26, 2018 at 5:50 AM Stack <[email protected]> wrote:
>
> Unless objection, I was going to add support for hbck2[1] into branch-2.0
> and branch-2.1; i.e. hbck2 support would show up on a point release in
> 2.1.1 and 2.0.3. hbck2 is made up of a client tool that lives at
> hbase-hbck2 and a new HbckService hosted by the Master. It is the latter
> that would be added on point release.
>
> This goes against our general philosophy of bug-fixes only on point-release
> but the thinking is that we make an exception for a critical 'fixup' tool.
>
> Some notes:
>
> * Above comes of some discussion done on the tail of
> https://issues.apache.org/jira/browse/HBASE-19121
> * The 2.1.0 and <= 2.0.2 releases have no hbck2 support. The hbck2 tool
> will exit and ask the user upgrade.
> * The suggestion that hbck2 only show up in the next minor release --
> 2.2.0 -- was shot down because it would leave branch-2.0 and branch-2.1
> releases without a fixup tooling.
> * The HbckService is distinct and should not disturb normal operation. It
> exposes new API for the hbck2 client tool to pull on. It is not exposed as
> 'public' and is awkward to get at so should not show up on user's radar
> other than via the hbck2 client tool (TODO: verify).
>
> Shout if you think otherwise.
> Thanks,
> S
>
> 1. hbck2 is the replacement for the original hbck tool. hbck (A.K.A hbck1)
> does not work against hbase-2.x clusters.
