[
https://issues.apache.org/jira/browse/YARN-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546988#comment-13546988
]
Daryn Sharp commented on YARN-320:
----------------------------------
Admittedly, extracting the renewer is a bit dubious. It was the simplest way
to satisfy the ADTSM checks w/o making changes to the core that would have a
larger impact.
In 1.x I tried to make the JT not do a lookback RPC to itself, but I don't
recall why it was dinged. With the current design I'm not sure there's a good
way for the token to get access to the RM's secret manager, but yes that would
be ideal.
Thanks, I'll wrap up the patch.
> RM should always be able to renew its own tokens
> ------------------------------------------------
>
> Key: YARN-320
> URL: https://issues.apache.org/jira/browse/YARN-320
> Project: Hadoop YARN
> Issue Type: Bug
> Components: resourcemanager
> Affects Versions: 3.0.0, 2.0.3-alpha, 0.23.6
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Priority: Blocker
> Attachments: YARN-320.branch-23.patch
>
>
> YARN-280 introduced fast-fail for job submissions with bad tokens.
> Unfortunately, other stack components like oozie and customers are acquiring
> RM tokens with a hardcoded dummy renewer value. These jobs would fail after
> 24 hours because the RM token couldn't be renewed, but fast-fail is failing
> them immediately. The RM should always be able to renew its own tokens
> submitted with a job. The renewer field may continue to specify an external
> user who can renew.
--
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
