Jian He commented on YARN-3103:

patch looks good to me.

bq. In addition the AMRMClientImpl grabs the login user rather than the current 
user when security is enabled
[~xgong], do you recall why this change is made? maybe it didn't work on secure 
cluster when using the current ugi?  Jason, does the patch work on secure 
cluster too? 

bq. 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 
make sense, I missed the part that we already got a handle from 
AllocateResponse. {{ClientRMProxy#setAMRMTokenService}} now loops the existing 
tokens and set the token service name. If we support multiple AMRM tokens, this 
code will break too. Anyway, this can be addressed later.

bq. 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.
In MRAppMaster#initAndStartAppMaster, will it work if we insert the correct 
key/alias when adding credentials into appMasterUgi ?

bq. If we do above, then we don't need the cluster ID?
I meant given we already have a way to uniquely identify the AMRMToken on AM 
side based on the concatenated RM addresses. we may not need an extra cluster 
ID to uniquely identify the 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
>         Attachments: YARN-3103.001.patch
> 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