[
https://issues.apache.org/jira/browse/YARN-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14999697#comment-14999697
]
Li Lu commented on YARN-4183:
-----------------------------
Thanks [~vinodkv]! I agree we should find some better ways to organize
\*.enabled in ATS (we've got two different versions in our code base and will
add two more). For end users, we need to provide mechanisms to distinguish at
least 3 versions of ATS API calls, v1, 1.5, and v2 in future.
bq. There should be an explicit yarn.timeline-service.version which tells
YarnClient to get tokens or not - yes for non-present version (default), v1, v2
but no for v1.5.
bq. The version field has semantics on both client and server side at the same
time - it's picking a solution end-to-end.
IIUC, the newly proposed {{yarn.timeline-service.version}} supports a sanity
check mechanism: each API should check if the current running ATS's version is
equal to or higher than it's required version. For example, when a ATS v1.5 API
is called, but {{yarn.timeline-service.version}} is set to v1, it should simply
throw an exception. We can also decide if we need to get tokens or not in YARN
client by checking this version number.
We can distinguish API versions through their names. We need to keep the V1
APIs unchanged, but add V15 and V2 after the new APIs to clarify their API
version. Inside each V15 and V2 API we can perform the sanity check.
Let's make the {{yarn.timeline-service.version}} change here. We can modify
V1.5 APIs in YARN-4233/YARN-4234 and V2 APIs as a subtask of YARN-2928. I can
open a new subtask in YARN-2928 to fix this for V2.
> Enabling generic application history forces every job to get a timeline
> service delegation token
> ------------------------------------------------------------------------------------------------
>
> Key: YARN-4183
> URL: https://issues.apache.org/jira/browse/YARN-4183
> Project: Hadoop YARN
> Issue Type: Bug
> Affects Versions: 2.7.1
> Reporter: Mit Desai
> Assignee: Mit Desai
> Fix For: 3.0.0, 2.8.0, 2.7.2
>
> Attachments: YARN-4183.1.patch
>
>
> When enabling just the Generic History Server and not the timeline server,
> the system metrics publisher will not publish the events to the timeline
> store as it checks if the timeline server and system metrics publisher are
> enabled before creating a timeline client.
> To make it work, if the timeline service flag is turned on, it will force
> every yarn application to get a delegation token.
> Instead of checking if timeline service is enabled, we should be checking if
> application history server is enabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
