Li Lu commented on YARN-4356:

Hi [~sjlee0], thanks for the work! Mostly LGTM, just a few thing to check:
1. I noticed in some files we're verifying v2 in a hard-coded fashion (version 
== 2). Why do we still need this especially when we have 
2. MapRed will use the timeline.version config as the current active API 
version. I'm fine with this design. One thing to check: do we allow other 
applications to customize the active API version for themselves? That is, if 
the timeline-service.version is set to 2.x in future, are the applications 
allowed to use other versions of ATS? (I think in this case the compatibility 
story should be made by the application itself? )
3. ApplicationMaster, function names "...OnNewTimelineService" can be more 
specific like "...V2"?
4. ContainerManagerImpl, I just want to double check one behavior: the SMP is 
enabled for the NM only when timeline version is v2 and SMP is enabled in the 
config? What about v1.x versions? If this is a v2 only feature, shall we 
clarify that in the log message? 


> ensure the timeline service v.2 is disabled cleanly and has no impact when 
> it's turned off
> ------------------------------------------------------------------------------------------
>                 Key: YARN-4356
>                 URL: https://issues.apache.org/jira/browse/YARN-4356
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>    Affects Versions: YARN-2928
>            Reporter: Sangjin Lee
>            Assignee: Sangjin Lee
>            Priority: Critical
>              Labels: yarn-2928-1st-milestone
>         Attachments: YARN-4356-feature-YARN-2928.002.patch, 
> YARN-4356-feature-YARN-2928.003.patch, 
> YARN-4356-feature-YARN-2928.poc.001.patch
> For us to be able to merge the first milestone drop to trunk, we want to 
> ensure that once disabled the timeline service v.2 has no impact from the 
> server side to the client side. If the timeline service is not enabled, no 
> action should be done. If v.1 is enabled but not v.2, v.1 should behave the 
> same as it does before the merge.

This message was sent by Atlassian JIRA

Reply via email to