[
https://issues.apache.org/jira/browse/YARN-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004962#comment-15004962
]
Li Lu commented on YARN-4183:
-----------------------------
bq. With v.2 and especially early on with v.2, it would be rather useful to be
able to enable both v.1 (or v.1.5) and v.2. That would provide a useful
verification and comparison environment with a single cluster. The way it's
being discussed right now, it sounds like the version would be a single value
(mutually exclusive). Wouldn't it be good to have a possibility to be able to
enable more than one version? Thoughts?
+1. I don't see a fundamental challenge to support "1", "1.5", and "1, 2" at
the same time. One thing we need to be careful about is the meaning of the
incremental relationships between v1 and v1.5. Having "1.5" in the config means
the server supports ATS v1 API up to v1.5, but having "2" in the config does
not indicate any support to ATS v1?
bq. I think it's a completely compatible interpretation it also means strongly
that the server-side can interpret this as an instruction to enable all things
timeline service.
I agree. If it does not explicitly have a "client" in the config key, I think
it is much safer to _not_ to make this assumption.
bq. For example, I don't think we can make a guarantee that v.2 will be able
to support all queries for v.1 and v.1.5. What's more appropriate is an exact
match.
Yes. I think the confusion here comes from the relationships between v1, v1.5
and v2. Does my proposal work here?
> Enabling generic application history forces every job to get a timeline
> service delegation token
> ------------------------------------------------------------------------------------------------
>
> Key: YARN-4183
> URL: https://issues.apache.org/jira/browse/YARN-4183
> Project: Hadoop YARN
> Issue Type: Bug
> Affects Versions: 2.7.1
> Reporter: Mit Desai
> Assignee: Mit Desai
> Attachments: YARN-4183.1.patch
>
>
> When enabling just the Generic History Server and not the timeline server,
> the system metrics publisher will not publish the events to the timeline
> store as it checks if the timeline server and system metrics publisher are
> enabled before creating a timeline client.
> To make it work, if the timeline service flag is turned on, it will force
> every yarn application to get a delegation token.
> Instead of checking if timeline service is enabled, we should be checking if
> application history server is enabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
