Li Lu commented on YARN-3623:

Thanks for the review [~djp]! The ATS v1.5 introduces some new API on top of 
ATS v1 APIs. However, ATS v2 is not compatible with either versions. I agree 
that a config would suffice to specify the "active" ATS version or the version 
of the writer API a client should use. Right now I think a config with name 
"yarn.timeline-service.version" is fine because this leaves flexibility to 
allow a set of active ATS writer API versions in the system. Marking a latest 
version may not be quite useful since ATS 1.x is not API-compatible with ATS 

On the other hand, I totally agree there should be a comprehensive story for 
ATS rolling upgrade. IIUC, ATS v1 can be upgraded in a rolling fashion to v1.5. 
Meanwhile, if the ATS v1/1.5 server is available in the system, v1.x server 
should be able to work with v2.x clients (since the v1 server won't be touched 
by ATS v2 client). Therefore, I think the rolling upgrade story, from ATS v1.x 
to ATS v2, can be reduced to the ability for ATS v1 servers and ATS v2 can 
co-exist in the cluster? We can certainly have more discussion on the rolling 
upgrade in ATS v2 JIRAs. 

> 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: Xuan Gong
>         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

Reply via email to