+1 for adding hbck2 on a point release. Agree that it is an "operator tooling" than "new feature" . Best Regards Allan Yang
Sean Busbey <bus...@apache.org> 于2018年9月27日周四 上午12:12写道： > 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 <st...@duboce.net> 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. >
