[
https://issues.apache.org/jira/browse/YARN-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294346#comment-14294346
]
Jian He commented on YARN-3103:
-------------------------------
bq. I'm missing how we're going to remove the old token with teh empty service
name if Credentials doesn't let you remove tokens?
We may need to expose UserGroupInformation#getCredentialsInternal to be public
and add a Credentials#removeToken method which can remove the token from the
Credentials#tokenMap, ClientRMProxy call
{{UserGroupInformation#getCurrentUser()#getCredentialsInternal#removeToken(serviceName)}},
though this doesn't look good..
bq. Unfortunately I don't think it's guaranteed, since the client doesn't seem
to need it to function properly.
right. today cluster ID is defined in yarn-site.xml. It's not guaranteed each
AM has the right cluster ID defined in its yarn-site.xml;
> 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)
