Jason Lowe commented on YARN-3103:

In general it seems very hazardous to assume nobody else will ever try to put a 
token into a credentials map associated with an empty service name.  It's just 
begging for two unrelated tokens to accidentally clobber each other.  IMHO the 
RM should add the AMRM token to the credentials using a well-known identifier 
that the client can also use when updating it.  For example, rather than the RM 
poking the token in with an empty service name, it could do something like this 

    // Add AMRMToken
    Token<AMRMTokenIdentifier> amrmToken = createAndSetAMRMToken();
    if (amrmToken != null) {
amrmToken.getService(), amrmToken);

And clients could expect to associate any updated AMRM token from the RM in a 
similar fashion, poking it into the credentials using the KIND_NAME alias 
rather than relying on the implicit service name mapping done with 
UserGroupInformation.addToken(Token) form.   That way we're helping to isolate 
the token from other tokens.  The client would be free to update the service 
name of the token and know that when it pokes it back into the credentials it 
will be replacing the existing token.

> 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

Reply via email to