HBASE-21393 already hit a case where the maintenance version will matter (e.g. works in 2.1.2 but not 2.1.1).
I don't see how tracking ever more complicated sets of version numbers in HBCK2 is going to be simpler than an API in the service that can send back some strings. On Wed, Apr 3, 2019 at 5:46 AM Wellington Chevreuil < [email protected]> wrote: > Unfortunately, if we plan to have an hbck2 capable of evolving ahead of > server/master API, version mappings between hbck2/hbase project seems > unavoidable. I guess it would need to rely on best practices guidelines, > such as making sure to document minimal hbase version required for new > methods relying on server/master API. Maybe a framework for commands > implementation, where remote methods would be invoked reflectively, to > avoid compile time headache of finding the most recent hbck2 version that > compiles against target cluster hbase version. > > Em ter, 2 de abr de 2019 às 18:53, Stack <[email protected]> escreveu: > > > 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 > > > > > > > > > >
