Can't we adjust the REST server to not need YARN? On Mon, Apr 27, 2020 at 5:21 PM Josh Elser <[email protected]> wrote:
> I'd think we'd want to approach that the other way around. Shade what > Jersey we need for REST, and (continue to) let Hadoop run wild. > > Locking ourselves to specific upstream YARN jars worries me. > > On 4/27/20 5:05 PM, Nick Dimiduk wrote: > > I suppose an alternative is to provide a shaded version of the YARN jars > > needed by hbase-rest in hbase-thirdparty. We'd need these for both > hadoop2 > > and hadoop3, to pull them in via profile, and to exclude the originals > > wherever they appear as transitive deps (though they shouldn't, right?) > > > > On Mon, Apr 27, 2020 at 11:24 AM Josh Elser <[email protected]> wrote: > > > >> > >> > >> On 4/27/20 1:52 PM, Nick Dimiduk wrote: > >>> On Mon, Apr 27, 2020 at 10:11 Stack<[email protected]> wrote: > >>> > >>>> On Mon, Apr 27, 2020 at 9:44 AM Josh Elser<[email protected]> wrote: > >>>> > >>>>> +1 to the idea, -0 to the implied execution > >>>>> > >>>>> I agree hbase-connectors is a better place for REST and thrift, long > >>>> term. > >>>>> My concern is that I read this thread as suggesting: > >>>>> > >>>>> 1. Remove rest/thrift from 2.3 > >>>>> 1a. Proceed with 2.3.0 rc's > >>>>> 2. Add rest/thrift to hbase-connectors > >>>>> ... > >>>>> n. Release hbase-connectors > >>>>> > >>>>> I'm not a fan of removing anything which was previously there until > >>>>> there is are new releases and documentation to tell me how to do it. > >> I'm > >>>>> still trying to help dig out another project who did the 'remove and > >>>>> then migrate" and left a pile of busted. > >>>>> > >>>>> If that's not what you were suggesting, let me shirk back into the > >>>>> shadows;) > >>>>> > >>>> > >>>> Ha ha. Not what I was suggesting but that could for sure happen. > >>>> > >>>> S > >>>> > >>>> P.S. I'm having trouble w/ REST jersey1 vs jersey2 vs Hadoop3 > transitive > >>>> includes++. Thrift has sporadic test failures that seem inherent to > >> thrift > >>>> rather of our manufacture. The discussion here was provoked by a > >> daydream > >>>> that bringing forward this inevitable migration of REST+thrift would > >>>> 'solve' my immediate pain. Wasn't giving too much mind to the amount > of > >>>> work needed on the other side. > >>> > >>> I’m not clear on how moving the module out will resolve the class path > >>> issues. Whether it’s built from the main repo or from the side repo, > >> yarn’s > >>> transitive hull is still present... > >>> > >> > >> Yeah, understandable :) > >> > >> I think working with "something" for REST/Thrift in connectors (punt on > >> H3 to start?) is reasonable. You shouldn't be stuck with the baggage of > >> Jersey dependencies if that's not the problem you're trying to solve. > >> > > >
