[
https://issues.apache.org/jira/browse/HADOOP-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907746#comment-15907746
]
Rushabh S Shah commented on HADOOP-14104:
-----------------------------------------
bq. This means, If encryption is not enabled, then we don't put any entry into
the secretMap, and each task of mapreduce job will always call
getServerDefaults, which we try to avoid.
I don't follow this.
{{DFSClient#isHDFSEncryptionEnabled}} is being only called by
{{DistributedFileSystem#addDelegationTokens}} (job submission) and
{{DistributedFileSystem.getTrashRoot}} (FSShell commands).
{{DFSClient#getKeyProvider}} is being called by
{{DistributedFileSystem#addDelegationTokens}} (again job submission) and
{{DFSClient#decryptEncryptedDataEncryptionKey}}.
When calling via {{DFSClient#decryptEncryptedDataEncryptionKey}}, we already
know that this directory or parent directory is already encrypted.
So I don't understand why each mapreduce task which is accessing
{{non-encrypted directory}} will call getKeyProvider and in turn call
serverDefaults ?
Am I missing something ?
> Client should always ask namenode for kms provider path.
> --------------------------------------------------------
>
> Key: HADOOP-14104
> URL: https://issues.apache.org/jira/browse/HADOOP-14104
> Project: Hadoop Common
> Issue Type: Improvement
> Components: kms
> Reporter: Rushabh S Shah
> Assignee: Rushabh S Shah
> Attachments: HADOOP-14104-trunk.patch, HADOOP-14104-trunk-v1.patch,
> HADOOP-14104-trunk-v2.patch
>
>
> According to current implementation of kms provider in client conf, there can
> only be one kms.
> In multi-cluster environment, if a client is reading encrypted data from
> multiple clusters it will only get kms token for local cluster.
> Not sure whether the target version is correct or not.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
