[
https://issues.apache.org/jira/browse/HDFS-12621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199141#comment-16199141
]
Erik Krogen commented on HDFS-12621:
------------------------------------
{{addDelegationTokens}} had to be added to accommodate the fact that a single
FileSystem may have >1 DT which was not previously true. So a new API had to be
added.
To work around this same issue, HDFS router-based federation (HDFS-10467)
proposed using a "dummy" DT which represented the combination of all necessary
DTs. The router would maintain as part of its state a mapping from dummy DTs to
real DTs. Then, when the dummy was used by a client, the router would look up
the correct DT (based on which NN was being communicated with) and forward that
along. I'm not sure if the same approach would work here but it may be worth
considering.
> Inconsistency/confusion around ViewFileSystem.getDelagation
> ------------------------------------------------------------
>
> Key: HDFS-12621
> URL: https://issues.apache.org/jira/browse/HDFS-12621
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.7.3
> Reporter: Mohammad Kamrul Islam
>
> *Symptom*:
> When a user invokes ViewFileSystem.getDelegationToken(String renewer), she
> gets a "null". However, for any other file system, it returns a valid
> delegation token. For a normal user, it is very confusing and it takes
> substantial time to debug/find out an alternative.
> *Root Cause:*
> ViewFileSystem inherits the basic implementation from
> FileSystem.getDelegationToken() that returns "_null_". The comments in the
> source code indicates not to use it and instead use addDelegationTokens().
> However, it works fine DistributedFileSystem.
> In short, the same client call is working for hdfs:// but not for viewfs://.
> And there is no way of end-user to identify the root cause. This also creates
> a lot of confusion for any service that are supposed to work for both viewfs
> and hdfs.
> *Possible Solution*:
> _Option 1:_ Add a LOG.warn() with reasons/alternative before returning
> "null" in the base class.
> _Option 2:_ As done for other FS, ViewFileSystem can override the method with
> a implementation by returning the token related to fs.defaultFS. In this
> case, the defaultFS is something like "viewfs://..". We need to find out the
> actual namenode and uses that to retrieve the delegation token.
> _Option 3:_ Open for suggestion ?
> *Last note:* My hunch is : there are very few users who may be using
> viewfs:// with Kerberos. Therefore, it was not being exposed earlier.
> I'm working on a good solution. Please add your suggestion.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
