Hi Vinod, The HDFS-8155 work is complete in branch-2 already, so feel free to include it in the roadmap.
For those watching the thread that aren't familiar with HDFS-8155, I want to call out that it was a client-side change only. The WebHDFS client is capable of obtaining OAuth2 tokens and passing them along in its HTTP requests. The NameNode and DataNode server side currently do not have any support for OAuth2, so overall, this feature is only useful in some very unique deployment architectures right now. This is all discussed explicitly in documentation committed with HDFS-8155, but I wanted to prevent any mistaken assumptions for people only reading this thread. --Chris Nauroth On 11/25/15, 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 >>> >
