[jira] [Commented] (HDFS-12621) Inconsistency/confusion around ViewFileSystem.getDelagation

["Erik Krogen (JIRA)" <ji...@apache.org>]

    [ 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: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org