hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Lowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3103) AMRMClientImpl does not update AMRM token properly
Date Wed, 28 Jan 2015 14:40:34 GMT

    [ https://issues.apache.org/jira/browse/YARN-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295216#comment-14295216

Jason Lowe commented on YARN-3103:

On second thought, maybe the client doesn't need to know the service name the RM used.  The
RM is already sending an updated token _that the RM generated_ to the AM.  If the AM blindly
stuffs it into the credentials _before_ it tries to fixup the token then it will use whatever
service name the RM left on the token.  As long as that service name matches the one the RM
put in originally (and ideally it's not going to collide with any other token) then we know
it will clobber the old AMRM token as intended.  Then the client can fixup the token service
name _after_ it's been stored in the credentials, just like it does during AM startup.

So we just need the AM to generate something that will not collide with non-AMRM tokens and
also not collide with tokens from other cluster RMs.  Cluster ID is tempting, but if the AM
is talking to two, non-HA clusters then I'm not sure we know the user bothered to configure
the cluster ID.  However I think we _have_ to use the cluster ID otherwise two RMs in the
same HA-enabled cluster could generate different service names which breaks things.  So I
think the cluster ID is our best bet, with the caveat that if an AM needs to wield multiple
AMRM tokens then all clusters involved need to have unique cluster IDs configured.  Thoughts?

> 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

View raw message