Hey Vinod, I'm fine with the idea of alpha/beta marking in the abstract, but had a question: do we define these terms in our compatibility policy or elsewhere? I think it's commonly understood among us developers (alpha means not fully tested and API unstable, beta means it's not fully tested but is API stable), but it'd be good to have it written down.
Also I think we've only done alpha/beta tagging at the release-level previously which is a simpler story to tell users. So it's important for this release that alpha features set their interface stability annotations to "evolving". There isn't a corresponding annotation for "interface quality", but IMO that's overkill. Thanks, Andrew On Wed, Nov 25, 2015 at 11:08 AM, Vinod Kumar Vavilapalli < vino...@apache.org> wrote: > This is the current state from the feedback I gathered. > - Support priorities across applications within the same queue YARN-1963 > — Can push as an alpha / beta feature per Sunil > - YARN-1197 Support changing resources of an allocated container: > — Can push as an alpha/beta feature per Wangda > - YARN-3611 Support Docker Containers In LinuxContainerExecutor: Well > most of it anyways. > — Can push as an alpha feature. > - YARN Timeline Service v1.5 - YARN-4233 > — Should include per Li Lu > - YARN Timeline Service Next generation: YARN-2928 > — Per analysis from Sangjin, drop this from 2.8. > > One open feature status > - HDFS-8155 Support OAuth2 in WebHDFS: Alpha / Early feature? > > Updated the Roadmap wiki with the same. > > Thanks > +Vinod > > > On Nov 13, 2015, at 12:12 PM, Sangjin Lee <sj...@apache.org> wrote: > > > > I reviewed the current state of the YARN-2928 changes regarding its > impact > > if the timeline service v.2 is disabled. It does appear that there are a > > lot of things that still do get created and enabled unconditionally > > regardless of configuration. While this is understandable when we were > > working to implement the feature, this clearly needs to be cleaned up so > > that when disabled the timeline service v.2 doesn't impact other things. > > > > I filed a JIRA for that work: > > https://issues.apache.org/jira/browse/YARN-4356 > > > > We need to complete it before we can merge. > > > > Somewhat related is the status of the configuration and what it means in > > various contexts (client/app-side vs. server-side, v.1 vs. v.2, etc.). I > > know there is an ongoing discussion regarding YARN-4183. We'll need to > > reflect the outcome of that discussion. > > > > My overall impression of whether this can be done for 2.8 is that it > looks > > rather challenging given the suggested timeframe. We also need to > complete > > several major tasks before it is ready. > > > > Sangjin > > > > > > On Wed, Nov 11, 2015 at 5:49 PM, Sangjin Lee <sjl...@gmail.com> wrote: > > > >> > >> On Wed, Nov 11, 2015 at 12:13 PM, Vinod Vavilapalli < > >> vino...@hortonworks.com> wrote: > >> > >>> — YARN Timeline Service Next generation: YARN-2928: Lots of > momentum, > >>> but clearly a work in progress. Two options here > >>> — If it is safe to ship it into 2.8 in a disable manner, we can > >>> get the early code into trunk and all the way int o2.8. > >>> — If it is not safe, it organically rolls over into 2.9 > >>> > >> > >> I'll review the changes on YARN-2928 to see what impact it has (if any) > if > >> the timeline service v.2 is disabled. > >> > >> Another condition for it to make 2.8 is whether the branch will be in a > >> shape in a couple of weeks such that it adds value for folks that want > to > >> test it. Hopefully it will become clearer soon. > >> > >> Sangjin > >> > >
