[
https://issues.apache.org/jira/browse/HDFS-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843724#comment-15843724
]
Andrew Wang commented on HDFS-11210:
------------------------------------
Thanks for working on this Xiao, sorry for the slow review, comments and
questions:
High-level, is KeyProvider#clearCache intended for use by end-users? It looks
like we call clear after rollover in LBKMSCP automatically, but I could see a
"hadoop key" command being useful if there was a failure and you want to retry.
* I'd prefer "invalidate" to "clear", since "cache invalidation" is a known
term. e.g. invalidateCache, INVALIDATE_CACHE, etc.
* KMS.java, the debug log says "Rolling key with name", should probably say
"Invalidating cache for key with name" ?
* KMSCP, why was the drain in the rollover removed? I see a drain was added in
LBKMSCP, but what if we're not using that wrapper?
* KMSCP, since clearCache isn't implemented users can't call this except via
rollover (which calls clearServerCache). Is this intentional? I removed the
clearCache in TestKMS and it still passed.
* KeyProvider, should specify what the param is for clearCache in the Javadoc.
Also I think you meant "return the new key version" at the end of the
description.
* ValueQueue, you could have readLock(keyName) readUnlock(keyName) wrappers to
make it more concise, and also create the lock automatically.
* ValueQueue, do we need to worry about races to create locks in keyQueueLocks?
> Enhance key rolling to be atomic
> --------------------------------
>
> Key: HDFS-11210
> URL: https://issues.apache.org/jira/browse/HDFS-11210
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: encryption, kms
> Affects Versions: 2.6.5
> Reporter: Xiao Chen
> Assignee: Xiao Chen
> Attachments: HDFS-11210.01.patch
>
>
> To support re-encrypting EDEK, we need to make sure after a key is rolled, no
> old version EDEKs are used anymore. This includes various caches when
> generating EDEK.
> This is not true currently, simply because no such requirements / necessities
> before.
> This includes
> - Client Provider(s), and corresponding cache(s).
> When LoadBalancingKMSCP is used, we need to clear all KMSCPs.
> - KMS server instance(s), and corresponding cache(s)
> When KMS HA is configured with multiple KMS instances, only 1 will receive
> the {{rollNewVersion}} request, we need to make sure other instances are
> rolled too.
> - The Client instance inside NN(s), and corresponding cache(s)
> When {{hadoop key roll}} is succeeded, the client provider inside NN should
> be drained too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
