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?
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
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