hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bc Wong (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7295) Support arbitrary max expiration times for delegation token
Date Tue, 28 Oct 2014 19:22:34 GMT

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

bc Wong commented on HDFS-7295:

[~stevel@apache.org], I don't understand the scaling concern with revocation. I was thinking
that we can just cancel the DT with NN. And that's already supported. If the NN no longer
knows about a DT, then the requests using such a DT will automatically get rejected. No need
to keep a separate revocation list, unlike the X509 stuff.

This requires showing the HDFS admin what are all the outstanding DTs, and logging the DT
(a SHA hash) in the audit log. That latter facility is already in place today, and the SHA
hash of the DT is cached (HDFS-4680). This works at a pretty large scale for us. So I'm not
that concerned about perf here.

bq. pushing out new tokens from the client

When the Spark Streaming app is running, it's all in the cluster. It doesn't have any Kerberos
credential at that point. I don't think it can get new tokens. Right?

> Support arbitrary max expiration times for delegation token
> -----------------------------------------------------------
>                 Key: HDFS-7295
>                 URL: https://issues.apache.org/jira/browse/HDFS-7295
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>            Reporter: Anubhav Dhoot
>            Assignee: Anubhav Dhoot
> Currently the max lifetime of HDFS delegation tokens is hardcoded to 7 days. This is
a problem for different users of HDFS such as long running YARN apps. Users should be allowed
to optionally specify max lifetime for their tokens.

This message was sent by Atlassian JIRA

View raw message