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