hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinod Kumar Vavilapalli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3623) We should have a config to indicate the Timeline Service version
Date Thu, 19 Nov 2015 22:55:11 GMT

    [ https://issues.apache.org/jira/browse/YARN-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15014661#comment-15014661

Vinod Kumar Vavilapalli commented on YARN-3623:

Copying comments from YARN-4183 w.r.t versioning:

By Me
 - 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.
 - We should also use the same property in the new API calls proposed for V1.5 YARN-4233 /
V2 YARN-2928, lest the users think they can call any API independent of what is supported
on server side.
 - The version field has semantics on both client and server side at the same time - it's
picking a solution end-to-end.

By [~sjlee0]
 - The version is a list or enum - https://issues.apache.org/jira/browse/YARN-4183?focusedCommentId=15004954&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15004954.
Related JIRA: YARN-4368.

> We should have a config to indicate the Timeline Service version
> ----------------------------------------------------------------
>                 Key: YARN-3623
>                 URL: https://issues.apache.org/jira/browse/YARN-3623
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Zhijie Shen
>            Assignee: Naganarasimha G R
> So far RM, MR AM, DA AM added/changed new config to enable the feature to write the timeline
data to v2 server. It's good to have a YARN timeline-service.version config like timeline-service.enable
to indicate the version of the running timeline service with the given YARN cluster. It's
beneficial for users to more smoothly move from v1 to v2, as they don't need to change the
existing config, but switch this config from v1 to v2. And each framework doesn't need to
have their own v1/v2 config.

This message was sent by Atlassian JIRA

View raw message