Xuan Gong commented on YARN-4183:

Sorry for the late response.

Here is my understanding:
* The current problem is that all the jobs are enforced to get ATS DT even if 
those jobs do not want to connect in future.  
* The value for yarn.timeline-service.enabled only means whether we have ATS 
daemon or not. We should not use this configuration to decide whether the job 
needs to get the ATS DT. 
* I think that the part of the reason, why we marked this configuration 
"yarn.timeline-service.generic-application-history.enabled" as private instead 
of deleting it, is for the compatibility.

[~jeagles] I agree with all of your comments. But I think the concerns from 
[~Naganarasimha], especially  compatibility part, makes sense.

bq. If the main issue is for creation of delegation tokens i would rather 
prefer to have some option in the clients to determine whether to create create 
ATS delegations tokens or not. Thoughts?

It might be better if we could have options for the applications to choose 
whether they need ATS DT or not. 

> 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
>             Fix For: 3.0.0, 2.8.0, 2.7.2
>         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

Reply via email to