On Tue, Apr 2, 2019 at 7:14 AM Sean Busbey <[email protected]> wrote:
> Should we instead make sure the hbck service in master is more pluggable? > Is it poking at stuff going to be too version specific? > > I like the sentiment. Up to this, we've been adding API as we figure what we need. Meantime hbase's ship and are missing the latest API additions. More universal API-types would help I suppose though hard in practice or we could work on a means of loading code into Master or enabling an interpreter or some such (Or something like Allan's servlet loading trick). > Instead of version checking gymnastics in hbck2 could we have the hbck > service report available feature set? > > Strikes me as overkill at the moment but would be a nice addition. S > 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 > > >
