[
https://issues.apache.org/jira/browse/HDFS-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058286#comment-14058286
]
Yi Liu commented on HDFS-6474:
------------------------------
Thanks [~andrew.wang] for the patch. It’s great to use monitor and avoid a
synchronous RPC to the KMS on every create encrypted files within a zone.
{quote}
Namely, a review of the locking in regards to KeyProvider usage would be
appreciated
{quote}
I have go through the locking carefully, It’s great, not found issue from my
point of view. :)
My comments are:
*1.* We can get key version too when creating encryption zone. Then
{{latestEZKeyVersion}} always exists when creating encrypted files within a
zone, that’s more efficient.
*2.* In {{FSNamesystem}}, for {{startFileInt}} and {{startFileInternal}}, It
should work with current logic, but it couples {{newFileEncryptionInfo}} and
{{startFileInternal}}; {{newFileEncryptionInfo}} will need to create EKDK, and
we involve startFileInternal in unnecessary loop logic.
* If change it to following would look more clear:
a) do startFileInternal, but do not do {{getEditLog().logOpenFile}}
b) If the file is in encryption zone, then we do
newFileEncryptionInfo, and loop and handle the retry.
c) Finally we do {{getEditLog().logOpenFile}}
> Namenode needs to get the actual keys and iv from the KeyProvider
> -----------------------------------------------------------------
>
> Key: HDFS-6474
> URL: https://issues.apache.org/jira/browse/HDFS-6474
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode, security
> Reporter: Charles Lamb
> Assignee: Andrew Wang
> Attachments: hdfs-6474.001.patch
>
>
> The Namenode has code to connect to the KeyProvider, but it needs to actually
> get the keys and return them to the client at the right time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
