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.

{quote} 
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.
{quote}
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
(v6.3.15#6346)

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


Mime
View raw message