Thanks for your input, Eli. Since you mention libhdfs, now that hdfs PB protocols have stabilized, for quite some time, would folks think that a native C binding for hdfs belongs outside of HDFS? I think libyarn decision should be based on similar feeling too.
The other factor to consider is, that libyarn is based on yarn PB protocol. Current libhdfs impl is based on HDFS API. So, if someone were to implement yarn-api-compatible RM, libyarn would not work with it. (Similar to our proposal to implement libhdfs3 using HDFS protocol, which will not work with a dozen or so HCFS -Hadoop Compatible File Systems, that implement API compatibility.) So, what it boils down to, is this: 1. Protocol-based clients should remain close to implementations. 2. API-based clients can remain further away. Do yarn-developers agree to this characterization of clients? - milind Sent from my iPhone > On Oct 19, 2013, at 14:48, Eli Collins <[email protected]> wrote: > > Hey Milind, > > I think it should be up to the people working on it - if they want to > maintain it in github they should, if they want to contribute it to Yarn > they should. I think we've found it useful to have libhdfs maintained > in-tree for hdfs (allows us to update/release changes that introduce new > APIs in one shot), OTOH now that we've got maintained PB APIs you can more > realistically maintain language bindings out of tree. Either path seems > reasonable to me. > > Thanks, > Eli > > > On Sat, Oct 19, 2013 at 12:39 PM, Milind Bhandarkar < > [email protected]> wrote: > >> Hello Folks, >> >> >> >> I had sent a proposal for contributing libyarn, a native C interface for >> Yarn RM (Client-RM, AM-RM) last week. >> >> >> >> I guess some of you were busy in the 2.2 GA, so did not have time to reply. >> >> >> >> Now that 2.2 is GA, can you comment on whether libyarn belongs to Apache >> YARN or should it be hosted as an addendum elsewhere ? >> >> >> >> Thanks, >> >> >> >> - Milind >> >> - >>
