Okay, tx for this clarification Chris! I dug more into this and now realized 
the actual scope of this. Given the the limited nature of this feature 
(non-Namenode etc) and the WIP nature of the larger umbrella HADOOP-11744, we 
will ship the feature but I’ll stop calling this out as a notable feature.

Thanks
+Vinod


> On Nov 25, 2015, at 12:04 PM, Chris Nauroth <cnaur...@hortonworks.com> wrote:
> 
> 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
>>>> 
>> 
> 
> 

Reply via email to