[
https://issues.apache.org/jira/browse/YARN-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13539767#comment-13539767
]
Vinod Kumar Vavilapalli commented on YARN-279:
----------------------------------------------
+1 for the idea in general.
bq. For the sake of discussion, the implementation of a token's management
should be cleanly abstracted and removed from the RM. One approach would be to
require resources with tokens to provide a web service that implements renew
and cancel. The RM's renew timers then only call a REST api to manage the
tokens. A token would only need to contain a base uri for the REST call.
It should be an abstract service and I think we should for now push it to
JobHistoryServer and then move it to ApplicationHistoryServer when it arrives.
Abstract service in RM is the shortest path.
OTOH, implementing REST API for all the services is big enough task itself,
starting with HDFS. And we need to implement them all with kerberos-auth as
renewal/cancel is only supported for kerberos-auth for security reasons. So
let's separate that out.
> Generalize RM token management
> ------------------------------
>
> Key: YARN-279
> URL: https://issues.apache.org/jira/browse/YARN-279
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: resourcemanager
> Affects Versions: 3.0.0, 2.0.0-alpha, 0.23.5
> Reporter: Daryn Sharp
>
> Token renewal/cancelation in the RM presents challenges to support arbitrary
> tokens. The RM's CLASSPATH is currently required to have token renewer
> classes and all associated classes for the project's client. The logistics
> of having installs on the RM of all hadoop projects that submit jobs - just
> to support client connections to renew/cancel tokens - are untenable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
