[
https://issues.apache.org/jira/browse/YARN-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14272317#comment-14272317
]
Yongjun Zhang commented on YARN-3021:
-------------------------------------
{quote}
If we can have a way to tell YARN not to renew a token, and the client either
wants to just to use the lifetime of the token, or the client can renew itself
before the job finish, that will solve the problem. One possible solution is to
add a new parameter when submitting a job, or ro add a field in the job context.
{quote}
However, assume we have the API to let YARN not to renew the token, YARN might
still want to check whether a token submitted from client is valid. Currently
the validity checking is done in the renewal code described in
https://issues.apache.org/jira/browse/YARN-3021?focusedCommentId=14271642&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14271642
and Harsh's patch tries to fix. In other words, the renewal code serves as both
validating and renewing the token. There seems to be no dedicated API to check
validity.
In the scenario Harsh described, even if we have dedicated API to check token
validity, the check would fail too because realm A and B don't have trust, even
though the token is valid from realm B's point of view.
So my question is, should YARN support running a job without validating a
token? (Though MR1 "support" this because the token renewal is asynchronous as
Harsh pointed out).
Thanks.
> YARN's delegation-token handling disallows certain trust setups to operate
> properly
> -----------------------------------------------------------------------------------
>
> Key: YARN-3021
> URL: https://issues.apache.org/jira/browse/YARN-3021
> Project: Hadoop YARN
> Issue Type: Bug
> Components: security
> Affects Versions: 2.3.0
> Reporter: Harsh J
> Attachments: YARN-3021.patch
>
>
> Consider this scenario of 3 realms: A, B and COMMON, where A trusts COMMON,
> and B trusts COMMON (one way trusts both), and both A and B run HDFS + YARN
> clusters.
> Now if one logs in with a COMMON credential, and runs a job on A's YARN that
> needs to access B's HDFS (such as a DistCp), the operation fails in the RM,
> as it attempts a renewDelegationToken(…) synchronously during application
> submission (to validate the managed token before it adds it to a scheduler
> for automatic renewal). The call obviously fails cause B realm will not trust
> A's credentials (here, the RM's principal is the renewer).
> In the 1.x JobTracker the same call is present, but it is done asynchronously
> and once the renewal attempt failed we simply ceased to schedule any further
> attempts of renewals, rather than fail the job immediately.
> We should change the logic such that we attempt the renewal but go easy on
> the failure and skip the scheduling alone, rather than bubble back an error
> to the client, failing the app submission. This way the old behaviour is
> retained.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
