Jason Lowe commented on YARN-3103:

bq. I see. looks like Credentials doesn't have a removeToken method. If so, we 
may remove the old token with the empty service name.

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?

bq. Maybe use the cluster ID as the key ? active and standby RMs will share the 
same cluster ID. RMs from different cluster use different cluster IDs. 

This would be a good idea if we know with certainty that the client also knows 
the cluster ID.  It would need it to update the token with the appropriate 
service name to make sure it's clobbering the appropriate token.  Unfortunately 
I don't think it's guaranteed, since the client doesn't seem to need it to 
function properly.

> 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