Should we instead make sure the hbck service in master is more pluggable? Is it poking at stuff going to be too version specific?
Instead of version checking gymnastics in hbck2 could we have the hbck service report available feature set? On Mon, Apr 1, 2019 at 1:21 PM Stack <[email protected]> wrote: > On Mon, Apr 1, 2019 at 9:56 AM Wellington Chevreuil < > [email protected]> wrote: > > > .... > > > <!-- SNIP nice summary of hbck2 precepts--> > > > > > Am interested to hear what's the general opinion on the way to move > forward > > with hbck2? Should we completely discourage client bound logic patches > such > > as the one from HBASE-22143 ? > > > > > No. If in a bind -- need to change a state but don't have the facility on > the master to do it in the kosher way -- then you have no recourse but to > do 'dirty tricks' as HBASE-22143 does making use of 'private' Interfaces. > > What you think Wellington of checking master version in the client-side and > doing 'dirty tricks' version if master version is old but taking the > master-route when it provides support; i.e. when making a fix, we'd do two > versions: one via the ordained route of asking the master to make the > change for us, and then a workaround second version for those deploys that > don't currently have the master-side support? > > Thanks for bringing up this topic, > S >
