[jira] [Commented] (HADOOP-14324) Switch to fs.s3a.server-side-encryption.key as property for encryption secret; load via credential provider
[
https://issues.apache.org/jira/browse/HADOOP-14324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977343#comment-15977343
]
Steve Loughran commented on HADOOP-14324:
-
I'm going to highlight that pickup via getPassword() doesn't seem to pick up
property deprecation. This is going to be consistent across all uses...probably
something nobody has noticed
before.
> Switch to fs.s3a.server-side-encryption.key as property for encryption
> secret; load via credential provider
> ---
>
> Key: HADOOP-14324
> URL: https://issues.apache.org/jira/browse/HADOOP-14324
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 2.9.0
>Reporter: Steve Loughran
>Assignee: Steve Loughran
>Priority: Blocker
> Attachments: HADOOP-14324-branch-2-001.patch,
> HADOOP-14324-branch-2-002.patch
>
>
> Before this ships, can we rename {{fs.s3a.server-side-encryption-key}} to
> {{fs.s3a.server-side-encryption.key}}.
> This makes it consistent with all other .key secrets in S3A. so
> * simplifies documentation
> * reduces confusion "is it a - or a ."? This confusion is going to surface in
> config and support
> I know that CDH is shipping with the old key, but it'll be easy for them to
> add a deprecation property to handle the migration. I do at least what the
> ASF release to be stable before it ships.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-14324) Switch to fs.s3a.server-side-encryption.key as property for encryption secret; load via credential provider
[
https://issues.apache.org/jira/browse/HADOOP-14324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977066#comment-15977066
]
John Zhuge commented on HADOOP-14324:
-
bq. didn't know about that reload thing. Makes we think: should we move the
deprecation listings into hadoop-common, just to save on the hit of a reload of
everything?
Unfortunately moving deprecation listing to hadoop-common will force us to use
a string literal for the new key because the constant for the new key is
defined in hadoop-tools.
> Switch to fs.s3a.server-side-encryption.key as property for encryption
> secret; load via credential provider
> ---
>
> Key: HADOOP-14324
> URL: https://issues.apache.org/jira/browse/HADOOP-14324
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 2.9.0
>Reporter: Steve Loughran
>Assignee: Steve Loughran
>Priority: Blocker
> Attachments: HADOOP-14324-branch-2-001.patch,
> HADOOP-14324-branch-2-002.patch
>
>
> Before this ships, can we rename {{fs.s3a.server-side-encryption-key}} to
> {{fs.s3a.server-side-encryption.key}}.
> This makes it consistent with all other .key secrets in S3A. so
> * simplifies documentation
> * reduces confusion "is it a - or a ."? This confusion is going to surface in
> config and support
> I know that CDH is shipping with the old key, but it'll be easy for them to
> add a deprecation property to handle the migration. I do at least what the
> ASF release to be stable before it ships.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-14324) Switch to fs.s3a.server-side-encryption.key as property for encryption secret; load via credential provider
[
https://issues.apache.org/jira/browse/HADOOP-14324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977021#comment-15977021
]
John Zhuge commented on HADOOP-14324:
-
There is a known issue tracked by HADOOP-14251: if an old key is stored in cred
store, it can not be read by a new key.
> Switch to fs.s3a.server-side-encryption.key as property for encryption
> secret; load via credential provider
> ---
>
> Key: HADOOP-14324
> URL: https://issues.apache.org/jira/browse/HADOOP-14324
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 2.9.0
>Reporter: Steve Loughran
>Assignee: Steve Loughran
>Priority: Blocker
> Attachments: HADOOP-14324-branch-2-001.patch,
> HADOOP-14324-branch-2-002.patch
>
>
> Before this ships, can we rename {{fs.s3a.server-side-encryption-key}} to
> {{fs.s3a.server-side-encryption.key}}.
> This makes it consistent with all other .key secrets in S3A. so
> * simplifies documentation
> * reduces confusion "is it a - or a ."? This confusion is going to surface in
> config and support
> I know that CDH is shipping with the old key, but it'll be easy for them to
> add a deprecation property to handle the migration. I do at least what the
> ASF release to be stable before it ships.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-14324) Switch to fs.s3a.server-side-encryption.key as property for encryption secret; load via credential provider
[
https://issues.apache.org/jira/browse/HADOOP-14324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976959#comment-15976959
]
Steve Loughran commented on HADOOP-14324:
-
+need to make sure that {{getServerSideEncryptionKey}} goes via the credential
provider, ideally through a test.
it looks like it does, but given I had to read the code 2x to make sure, I'd
like the test. Easiest if I pull out the whole config validation logic into
S3AUtils for isolated testage
> Switch to fs.s3a.server-side-encryption.key as property for encryption
> secret; load via credential provider
> ---
>
> Key: HADOOP-14324
> URL: https://issues.apache.org/jira/browse/HADOOP-14324
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 2.9.0
>Reporter: Steve Loughran
>Assignee: Steve Loughran
>Priority: Blocker
> Attachments: HADOOP-14324-branch-2-001.patch,
> HADOOP-14324-branch-2-002.patch
>
>
> Before this ships, can we rename {{fs.s3a.server-side-encryption-key}} to
> {{fs.s3a.server-side-encryption.key}}.
> This makes it consistent with all other .key secrets in S3A. so
> * simplifies documentation
> * reduces confusion "is it a - or a ."? This confusion is going to surface in
> config and support
> I know that CDH is shipping with the old key, but it'll be easy for them to
> add a deprecation property to handle the migration. I do at least what the
> ASF release to be stable before it ships.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
