[
https://issues.apache.org/jira/browse/HADOOP-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422528#comment-13422528
]
Daryn Sharp commented on HADOOP-7967:
-------------------------------------
* getDelegationToken should have audience of HDFS and MapReduce. Why the
deprecate with a comment?
It was already deprecated, and is in fact no longer used by MR. The goal is to
eventually reduce the visibility to prevent external calls. Hence why I
removed MR from the audience.
* getDelegationTokens - remove from viewFileSystem test
Ok, assuming we don't keep it around a little longer (see next point).
* getDelegationTokens - remove this method - only 0.23 needs to keep it for
transition
We discussed that option before, but I think we may want to reconsider
retaining it as deprecated for at least one more alpha release.
{{getDelegationToken}} is supposedly limited audience to mapreduce and hdfs.
Unfortunately I found documentation, such as secure impersonation, that tells
people to use it! When {{getDelegationToken}} was deprecated in 1.x, the
javadocs referred people to {{getDelegationToken(S)}}. Abruptly removing
{{getDelegationToken(S)}} w/o notice might break other projects.
* collectDelegationTokens - add javadoc - esp the parameter returnAllTokens
It's a private method, but ok.
* collectDelegationTokens - Shouldn't the code be (or are you saying that a fs
can have its own token + those of its children)
Yes, I don't think an intrinsic token vs child tokens are mutually exclusive.
I'd like to make the api flexible to allow a fs to have its own token and/or
child tokens.
> Need generalized multi-token filesystem support
> -----------------------------------------------
>
> Key: HADOOP-7967
> URL: https://issues.apache.org/jira/browse/HADOOP-7967
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs, security
> Affects Versions: 0.23.1, 0.24.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Priority: Critical
> Attachments: HADOOP-7967-2.patch, HADOOP-7967-3.patch,
> HADOOP-7967-4.patch, HADOOP-7967-compat.patch, HADOOP-7967.newapi.2.patch,
> HADOOP-7967.newapi.patch, HADOOP-7967.patch
>
>
> Multi-token filesystem support and its interactions with the MR
> {{TokenCache}} is problematic. The {{TokenCache}} tries to assume it has the
> knowledge to know if the tokens for a filesystem are available, which it
> can't possibly know for multi-token filesystems. Filtered filesystems are
> also problematic, such as har on viewfs. When mergeFs is implemented, it too
> will become a problem with the current implementation. Currently
> {{FileSystem}} will leak tokens even when some tokens are already present.
> The decision for token acquisition, and which tokens, should be pushed all
> the way down into the {{FileSystem}} level. The {{TokenCache}} should be
> ignorant and simply request tokens from each {{FileSystem}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
