[ 
https://issues.apache.org/jira/browse/HADOOP-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033073#comment-16033073
 ] 

Sean Mackrory commented on HADOOP-14448:
----------------------------------------

+1 to that. I took a deeper look at this yesterday:

testDeleteEncryptedObjectWithDifferentKey, testListEncryptedDir, 
testListStatusEncryptedDir, testListStatusEncryptedFile fail with the DynamoDB 
implementation, but not with Local. Which is odd. When the tests do catch the 
expected exceptions, it's always because of the innerGetFileStatus -> 
s3GetFileStatus code path, which can be bypassed when there's a metadata store. 
So it makes sense that the tests are failing - so I'm generally supportive of 
just skipping in the S3Guard case. Should probably still investigate why it 
works with local at some point...

testCreateFileThenMoveWithDifferentSSECKey failed once but I can't reproduce 
it. testCreateSubdirWithDifferentKey is failing consistently for me in my 
branch but I still need to get a working trunk -> HADOOP-13345 merge and test 
it out there to try and debug a little more if it's not just my branch.

> Play nice with ITestS3AEncryptionSSEC
> -------------------------------------
>
>                 Key: HADOOP-14448
>                 URL: https://issues.apache.org/jira/browse/HADOOP-14448
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/s3
>    Affects Versions: HADOOP-13345
>            Reporter: Sean Mackrory
>
> HADOOP-14035 hasn't yet been merged with HADOOP-13345, but it adds tests that 
> will break when run with S3Guard enabled. It expects that certain filesystem 
> actions will throw exceptions when the client-provided encryption key is not 
> configured properly, but those actions may sometimes bypass S3 entirely 
> thanks to S3Guard (for example, getFileStatus may not actually need to invoke 
> s3GetFileStatus). If the exception is never thrown, the test fails.
> At a minimum we should tweak the tests so they definitely invoke S3 directly, 
> or just skip the offending tests when anything but the Null implementation is 
> in use. This also opens the larger question of whether or not S3Guard should 
> be serving up metadata that is otherwise only accessible when an encryption 
> key is provided.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to