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

Junping Du commented on YARN-3623:
----------------------------------

bq. I agree the rolling upgrade use case from v.1 to v.2 should be addressed. 
We had some offline discussion on this too. Since it is a pretty major item in 
and of itself and somewhat separate (being v.2-specific) from this specific 
JIRA, it may be sufficient to note it here and carry on that discussion on a 
v.2 subtask. Sound good?
Sounds good.

bq. I'm fine with the current name "yarn.timeline-service.version". I just want 
to clarify the interpretation of this config on the cluster side and on the 
client side.
If all of you are fine with current config name, I would compromise on this. 
Yes. More clarification is needed on this configuration so we should definitely 
update the description.

bq. On the cluster side, it should always be interpreted as precisely which 
version of the timeline service should be up. If 
"yarn.timeline-service.version" is 1.5, and "yarn.timeline-service.enabled" is 
true, it should be understood as the cluster should bring up the timeline 
service v.1.5 (and nothing else), and the client can expect that to be the case.
I would question on this. If "yarn.timeline-service.version" is 2 (after 
cluster is being upgrade), and we don't serve 1/1.5 ATS service any more, how 
can existing running applications survival for timeline services? Unless we 
have a clear answer in v2 that we will continue to maintain a ATS v1/v1.5 
service as a legacy daemon in v2 (I don't prefer this way), I don't think we 
should mark this config to indicate an unique version of ATS service running in 
the server side.

bq. On the client side, clearly a client that uses the same version should 
expect to succeed. If a client chooses to use a smaller version in spite of 
this, then depending on how robust the compatibility story is between versions, 
the results may vary (part of the rolling upgrade discussion included).
This works if we don't consider rolling upgrade case. For roll up cases, an 
running application/framework cannot switch its client version config if YARN 
cluster is upgrading to a new version ATS. We shouldn't claim that 
application's clients is expected to be no response if version is mis-match 
with serve or the user would misunderstand they have to kill these applications 
after upgrade. Instead, we should claim that client is not supposed to override 
this config that vary with cluster config unless they are pretty sure what 
cluster side are doing (like upgrading process, etc.).

> 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
(v6.3.4#6332)

Reply via email to