hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Varun Saxena (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MAPREDUCE-6838) [ATSv2 Security] Add timeline delegation token received in allocate response to UGI
Date Tue, 22 Aug 2017 03:38:00 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-6838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16136206#comment-16136206
] 

Varun Saxena edited comment on MAPREDUCE-6838 at 8/22/17 3:37 AM:
------------------------------------------------------------------

Thanks [~jianhe] for the comments.

bq. The comment says is OR condition where as the code is AND, which one is true?
The code condition is correct. Will change the comment.

bq. Also, when will the "delegationToken.getService()" be empty ?
These are just checks for sanity. As NodeTimelineCollectorManager belongs to timelineservice
module and this to yarn-common. So added these checks because change elsewhere should not
break code here. 

bq. it uses "SecurityUtil.getTokenServiceAddr(timelineToken)" to set the token service. Then
next time collectorAddr is not null because timelineServiceAddress is not null, it always
call "NetUtils.createSocketAddr(collectorAddr) " to set the token service. Is my understanding
correct? why not just consistently use one of them to make it look simpler?
So this is because we are polling on timelineservice address in another thread(entity dispatcher)
and as soon as it is found, we go on to publish. So there can be a potential race so I first
update the token and then the timeline address. I can write a comment in code to make this
clear.

bq. Does the collector address change if NM restarts? If so, we may have two keys(different
address) for two tokens in the UGI.
Yes, that's true but the token will be picked up by DelegationTokenAuthenticatedURL based
on current collector address. Could not find any API to remove the token from UGI. Not sure
why. Should we add one?



was (Author: varun_saxena):
Thanks [~jianhe] for the comments.

bq. The comment says is OR condition where as the code is AND, which one is true?
The code condition is correct. Will change the comment.

bq. Also, when will the "delegationToken.getService()" be empty ?
These are just checks for sanity. As NodeTimelineCollectorManager belongs to timelineservice
module and this to yarn-common. So added these checks because change elsewhere should not
break code here. 

bq. it uses "SecurityUtil.getTokenServiceAddr(timelineToken)" to set the token service. Then
next time collectorAddr is not null because timelineServiceAddress is not null, it always
call "NetUtils.createSocketAddr(collectorAddr) " to set the token service. Is my understanding
correct? why not just consistently use one of them to make it look simpler?
So this is because we are polling on timelineservice address in another thread(entity dispatcher)
and as soon as it is found, we go on to publish. So there can be a potential race so I first
update the token and then the timeline address. I can write a comment in code to make this
clear.

bq. Does the collector address change if NM restarts? If so, we may have two keys(different
address) for two tokens in the UGI.
Yes, that's true but the token will be picked up by DelegationTokenAuthenticatedURL based
on current collector address. Could not find any API to remove the token from UGI.


> [ATSv2 Security] Add timeline delegation token received in allocate response to UGI
> -----------------------------------------------------------------------------------
>
>                 Key: MAPREDUCE-6838
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6838
>             Project: Hadoop Map/Reduce
>          Issue Type: Sub-task
>            Reporter: Varun Saxena
>            Assignee: Varun Saxena
>              Labels: yarn-5355-merge-blocker
>             Fix For: YARN-5355
>
>         Attachments: MAPREDUCE-6838-YARN-5355.01.patch, MAPREDUCE-6838-YARN-5355.02.patch,
MAPREDUCE-6838-YARN-5355.03.patch, MAPREDUCE-6838-YARN-5355.04.patch, MAPREDUCE-6838-YARN-5355.05.patch,
MAPREDUCE-6838-YARN-5355.06.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: mapreduce-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-help@hadoop.apache.org


Mime
View raw message