hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jian He (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3103) AMRMClientImpl does not update AMRM token properly
Date Tue, 27 Jan 2015 22:48:34 GMT

    [ 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)

Mime
View raw message