hadoop-yarn-issues mailing list archives

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

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

Naganarasimha G R commented on YARN-3623:

Hi [~vinodkv], [~sjlee0], [~gtCarrera] & [~xgong],
If the above solution is fine then we can have following steps 
# make this jira as subjira of 1.5 and introduce the timeline version 
# As part of YARN-4183, we can create *"yarn.timeline-service.client.require-delegation-token"*
so that it fixes depency on *"yarn.timeline-service.enabled"* in the client side to get tokens
# YARN-4356 or a *new jira* can handle modifications and updates of timeline version in ATSv2
# Can raise new jira and handle REST interface support to get the supported ATS version and
config from the server for ATS 1.5
# Can raise new jira and handle version checking for the ATSv2 interface methods in TimelineClient.and
also fetching of version

> 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: Bug
>          Components: timelineserver
>            Reporter: Zhijie Shen
>            Assignee: Naganarasimha G R
>         Attachments: YARN-3623-2015-11-19.1.patch
> 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