hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rushabh S Shah (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HADOOP-14104) Client should always ask namenode for kms provider path.
Date Tue, 28 Feb 2017 15:40:45 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Rushabh S Shah updated HADOOP-14104:
    Status: Open  (was: Patch Available)

bq.     FtpConfigKeys and LocalConfigKeys, would still be nice to introduce a new variable
for documentation purposes
Will update in the next revision.
bq.    I dislike non-trivial ternary statements, mind rewriting DFSClient#getKeyProviderUri
a bit? 
Will update in next revision.
bq.We can also dedupe the call to getKeyProviderUri for clarity.
Can you please elaborate more ?

bq.     Still could use a doc update in TransparentEncryption.md about how this is fetched
from server-side defaults.
Will update in next revision.

Could you comment on potential additional overheads from invoking the NNto query this config
value? I don't see getServerDefaults used much right now, so it looks like this will add another
NN RPC to many client operations, for both unencrypted and encrypted clusters. This is concerning.
The results of {{namenode#getServerDefaults}} on DFSClient are cached for 1 hour.
On the namenode side also, this rpc call doesn't need any lock. So I don't think this should
add any significant load on Namenode.
For DFSInputStream, we already do call severDefaults to get {{DFSClient#newDataEncryptionKey}}

> 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
> 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

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

View raw message