hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Krogen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-12621) Inconsistency/confusion around ViewFileSystem.getDelagation
Date Mon, 16 Oct 2017 18:06:00 GMT

    [ https://issues.apache.org/jira/browse/HDFS-12621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16206309#comment-16206309

Erik Krogen commented on HDFS-12621:

I don't think Option 2 is the right approach; this goes against the general semantics of viewfs
and may be even more confusing to users if they have the right delegation tokens for some
paths but not others. I think that Option 1 is definitely a good idea given that we won't
be removing the method until Hadoop 4 at the earliest which is a long way away.

Do you have any thoughts on adapting a similar approach as router-based federation? I think
it is worth considering to see if there are any reasons why it is not possible. This approach
would actually allow the API to work properly until it is removed.

> 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
>            Assignee: 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
> _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

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

View raw message