hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Wang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6971) Bounded staleness of EDEK caches on the NN
Date Fri, 19 Sep 2014 09:41:34 GMT

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

Andrew Wang commented on HDFS-6971:

So we actually have caches in a number of places :) The CachingKeyProvider is actually on
the KMS. On the NN side, we're interacting with the KMSClientProvider. If you look at KMSClientProvider#generateEncryptedKey,
you'll see it interacting with a ValueQueue, which is the cache I was thinking about. I don't
think this is time-bounded.

If you could, you can also double check that CachingKeyProvider drops its cached encrypted
keys at the right times, i.e. on modify ops like deleteKey and rollNewVersion. As long as
it does so, I think we should be up-to-date.

> Bounded staleness of EDEK caches on the NN
> ------------------------------------------
>                 Key: HDFS-6971
>                 URL: https://issues.apache.org/jira/browse/HDFS-6971
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: encryption
>    Affects Versions: 2.5.0
>            Reporter: Andrew Wang
>            Assignee: Zhe Zhang
> The EDEK cache on the NN can hold onto keys after the admin has rolled the key. It'd
be good to time-bound the caches, perhaps also providing an explicit "flush" command.

This message was sent by Atlassian JIRA

View raw message