hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wei-Chiu Chuang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-10899) Add functionality to re-encrypt EDEKs
Date Thu, 03 Aug 2017 14:40:00 GMT

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

Wei-Chiu Chuang commented on HDFS-10899:

Still half way through my review. Post my notes for reference:

final boolean hasMore = (numResp < tailMap.size());
This seems untrue. if the system has 1001 (tailMap.size()) encryption zones, and we get 1
(count) encryption zone starting from the 1000th and we expect to get 100 results (numResp),
the hasMore should be false.
It looks like it would cause an infinite loop between client and NN because hasMore is _always_

Javadoc for HdfsAdmin#listReencryptionStatus:
This method can only be called by HDFS superusers.

This is a little unnecessary and misleading. 
By definition, methods in HdfsAdmin are superuser only.
Also, the permission check is enforced at namenode side, not client side.


@InterfaceAudience.Private annotation for ZoneReencryptionStatus

It seems EncryptionZoneManager#reencryptionHandler can be null if NN does not configure any
key providers.
So every access to reencryptionHandler should be checked to avoid NPE.

suggest a more appropriate method name — “fixReencryptionZoneNames” feels like a hack
for a bug.

EncryptionZoneManager#cancelReencryptEncryptionZone: the Javadoc “If the given path If the
given path is not the root of an encryption zone,” has duplicate words

Would ReencryptionStatus#getZoneStatus ever return null? 
The method is called by multiple callers so I can’t be sure if it is ever possible. But
it could return null, some value checking would be necessary for the callers.

IntelliJ is complaining that this code
TreeMap<String, FileEdekPair> batch = (TreeMap<String, FileEdekPair>)
FileEdekPair>) currentBatch).clone();
is an unchecked cast.

Append “millisecond” at the end of log message "Starting up re-encrypt thread with interval={}”

A number of typos
“inode cannot be resolve to a full path” : “resolve” —> resolved

> Add functionality to re-encrypt EDEKs
> -------------------------------------
>                 Key: HDFS-10899
>                 URL: https://issues.apache.org/jira/browse/HDFS-10899
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>          Components: encryption, kms
>            Reporter: Xiao Chen
>            Assignee: Xiao Chen
>         Attachments: editsStored, HDFS-10899.01.patch, HDFS-10899.02.patch, HDFS-10899.03.patch,
HDFS-10899.04.patch, HDFS-10899.05.patch, HDFS-10899.06.patch, HDFS-10899.07.patch, HDFS-10899.08.patch,
HDFS-10899.09.patch, HDFS-10899.10.patch, HDFS-10899.10.wip.patch, HDFS-10899.11.patch, HDFS-10899.12.patch,
HDFS-10899.wip.2.patch, HDFS-10899.wip.patch, Re-encrypt edek design doc.pdf, Re-encrypt edek
design doc V2.pdf
> Currently when an encryption zone (EZ) key is rotated, it only takes effect on new EDEKs.
We should provide a way to re-encrypt EDEKs after the EZ key rotation, for improved security.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message