[
https://issues.apache.org/jira/browse/HADOOP-14324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15977496#comment-15977496
]
Steve Loughran commented on HADOOP-14324:
-----------------------------------------
Example stack trace of the new error. This is running the integration tests
against a bucket in AWS london set to mandate AES256; auth-keys enables it too.
This breaks the SSEC test setup, which is a separate issue.
{code}
testEncryption(org.apache.hadoop.fs.s3a.ITestS3AEncryptionSSECBlockOutputStream)
Time elapsed: 0.07 sec <<< ERROR!
java.io.IOException: AES256 is enabled but an encryption key was set in
fs.s3a.server-side-encryption.key (key of length 44 ending with =)
at
org.apache.hadoop.fs.s3a.S3AUtils.getEncryptionAlgorithm(S3AUtils.java:797)
at
org.apache.hadoop.fs.s3a.S3AFileSystem.initialize(S3AFileSystem.java:260)
at
org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:3242)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:467)
at
org.apache.hadoop.fs.contract.AbstractBondedFSContract.init(AbstractBondedFSContract.java:72)
at
org.apache.hadoop.fs.contract.AbstractFSContractTestBase.setup(AbstractFSContractTestBase.java:177)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
{code}
> Switch to fs.s3a.server-side-encryption.key as property for encryption
> secret; improve error reporting and diagnostics
> ----------------------------------------------------------------------------------------------------------------------
>
> 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, HADOOP-14324-branch-2-003.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: [email protected]
For additional commands, e-mail: [email protected]
