[
https://issues.apache.org/jira/browse/HADOOP-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893268#comment-15893268
]
Andrew Wang commented on HADOOP-14104:
--------------------------------------
Hi Daryn, thanks for commenting! Looks like you have a more ambitious
implementation in mind, since your usecases include dynamic configuration
changes without client restarts (something not possible with the current
config-based approach).
Generally speaking, I think it's pretty rare to change the KMS URI. I think the
two situations are:
* Enabling HDFS encryption for the first time. This currently requires a client
restart.
* Enabling KMS HA. As long as the old KMS is part of the HA group, then clients
with the old value will still work.
Since the KMS is just a proxy, you can swap out the backing KeyProvider
implementation without changing the URI.
I'm not familiar with the Credentials APIs, but I like the sound of your
proposal. It lets most clients avoid calling getServerDefaults, which was my
main concern about the current patch.
Since we're very interested in a NN-specified KMS URI but less interested in
dynamic refresh, so if it's reasonable to do refresh as a follow-on JIRA,
that'd be optimal from our perspective.
> 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: [email protected]
For additional commands, e-mail: [email protected]
