[
https://issues.apache.org/jira/browse/HADOOP-11071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125860#comment-14125860
]
Alejandro Abdelnur commented on HADOOP-11071:
---------------------------------------------
Regarding addAll not being atomic, that is not an issue since atomicity is not
a concern and we are using threadsafe data structures. So I think we are good
there.
Regarding testing, the added test, using KMS, verifies the client & server
caches are drained because of a rollover, getting a new EEK produces an EEK
using the new key version. Note that under normal circumstances this is not the
typical scenario (the client rolling the key also consuming generated keys),
though this is exercised by HDFS-7006. In a typical usecase, a key shell
invocation will roll a key triggering the KMS to flush its server side
pre-generated EEKs, any client (ie HDFS NN) that has client side pre-generated
keys will continue consuming the pre-generated EEKs with the prior key version.
This means that there is a maximum number of EEKs with the prior key version
that can used after a rollover. If this a is a concern, client side
pre-generated keys may be disabled in the NN with a performance trade off. IMO,
it is reasonable to assume that at most X (X being the client side
pre-generated EEK cache) EEK with a prior key version will be used.
test failure is due to too many open files.
> KMSClientProvider should drain the local generated EEK cache on key rollover
> ----------------------------------------------------------------------------
>
> Key: HADOOP-11071
> URL: https://issues.apache.org/jira/browse/HADOOP-11071
> Project: Hadoop Common
> Issue Type: Test
> Components: security
> Affects Versions: 2.6.0
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Priority: Minor
> Attachments: HADOOP-11071.patch, HADOOP-11071.patch,
> HADOOP-11071.patch, HADOOP-11071.patch
>
>
> This is for formal correctness and to enable HDFS EZ to verify a rollover
> when testing with KMS
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)