Details
-
Sub-task
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
Reviewed
Description
This is part of YARN-613.
As per the updated design, AM will receive per NM, NMToken in following scenarios
- AM is receiving first container on underlying NM.
- AM is receiving container on underlying NM after either NM or RM rebooted.
- After RM reboot, as RM doesn't remember (persist) the information about keys issued per AM per NM, it will reissue tokens in case AM gets new container on underlying NM. However on NM side NM will still retain older token until it receives new token to support long running jobs (in work preserving environment).
- After NM reboot, RM will delete the token information corresponding to that AM for all AMs.
- AM is receiving container on underlying NM after NMToken master key is rolled over on RM side.
In all the cases if AM receives new NMToken then it is suppose to store it for future NM communication until it receives a new one.
AMRMClient should expose these NMToken to client.
Attachments
Attachments
Issue Links
- blocks
-
YARN-610 ClientToken (ClientToAMToken) should not be set in the environment
- Closed
-
YARN-613 Create NM proxy per NM instead of per container
- Closed
-
YARN-694 Start using NMTokens to authenticate all communication with NM
- Closed
-
YARN-739 NM startContainer should validate the NodeId
- Closed
- is blocked by
-
YARN-692 Creating NMToken master key on RM and sharing it with NM as a part of RM-NM heartbeat.
- Closed
-
YARN-714 AMRM protocol changes for sending NMToken list
- Closed
- relates to
-
YARN-1189 NMTokenSecretManagerInNM is not being told when applications have finished
- Closed