[
https://issues.apache.org/jira/browse/YARN-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295595#comment-14295595
]
Jason Lowe commented on YARN-3103:
----------------------------------
bq. we can loop the existing tokens in UGI and select out the AMRMToken based
on token kind and set the token service name.
That will be problematic with multiple AMRM tokens, since we won't know which
token is which. Also, we have the token in-hand from the AllocateResponse
call, no need to go hunting for it -- or are you thinking of a different
scenario?
bq. Or another way is to fix AM startup to inject the correct AMRMToken service
name instead of empty string.
AM startup already fixes the service name of the token, but it does not (and
cannot) change the key/alias associated with the token in the credentials.
Without changing UserGroupInformation to return a modifiable credentials and
modifying Credentials to let us remove tokens, I don't see how we can update
the key/alias associated with a token in the Credentials.
bq. Currently, AMRMToken service name is reset on AM side with a concatenated
string of multiple RM addresses; If we do above, then we don't need the cluster
ID?
The key/alias associated with the AMRM token is determined by the RM since it
stuffs the token into the AM's credentials as part of the AM launch process.
If we can't change the key/alias once established then this is something only
the RM can do.
> AMRMClientImpl does not update AMRM token properly
> --------------------------------------------------
>
> Key: YARN-3103
> URL: https://issues.apache.org/jira/browse/YARN-3103
> Project: Hadoop YARN
> Issue Type: Bug
> Components: client
> Affects Versions: 2.6.0
> Reporter: Jason Lowe
> Assignee: Jason Lowe
> Priority: Blocker
>
> AMRMClientImpl.updateAMRMToken updates the token service _before_ storing it
> to the credentials, so the token is mapped using the newly updated service
> rather than the empty service that was used when the RM created the original
> AMRM token. This leads to two AMRM tokens in the credentials and can still
> fail if the AMRMTokenSelector picks the wrong one.
> In addition the AMRMClientImpl grabs the login user rather than the current
> user when security is enabled, so it's likely the UGI being updated is not
> the UGI that will be used when reconnecting to the RM.
> The end result is that AMs can fail with invalid token errors when trying to
> reconnect to an RM after a new AMRM secret has been activated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
