[jira] [Updated] (YARN-3103) AMRMClientImpl does not update AMRM token properly
[ https://issues.apache.org/jira/browse/YARN-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kumar Vavilapalli updated YARN-3103: -- Fix Version/s: 2.6.1 Pulled this into 2.6.1. Ran compilation and TestAMRMClient before the push. Patch applied cleanly. > 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 > Labels: 2.6.1-candidate > Fix For: 2.7.0, 2.6.1 > > 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 (v6.3.4#6332)
[jira] [Updated] (YARN-3103) AMRMClientImpl does not update AMRM token properly
[ https://issues.apache.org/jira/browse/YARN-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kumar Vavilapalli updated YARN-3103: -- Labels: 2.6.1-candidate (was: ) 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 Labels: 2.6.1-candidate Fix For: 2.7.0 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 (v6.3.4#6332)
[jira] [Updated] (YARN-3103) AMRMClientImpl does not update AMRM token properly
[ https://issues.apache.org/jira/browse/YARN-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Lowe updated YARN-3103: - Attachment: YARN-3103.001.patch Attaching a patch that fixes which UGI is being updated along with updating the test to properly emulate what the RM is doing when setting up the UGI originally for the AM. Without the fix the test now fails by detecting there are multiple AMRM tokens in the UGI during the AMRM token update test. Note that this patch does not address the issue of what the RM should use for a service name when setting up the AMRM token. It just preserves whatever string the RM sent when adding the token to the UGI then updates it afterwards. We can address the empty service name issue in a followup JIRA. 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 (v6.3.4#6332)
