[jira] [Commented] (HADOOP-14448) Play nice with ITestS3AEncryptionSSEC

["Steve Loughran (JIRA)" <ji...@apache.org>]

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

Steve Loughran commented on HADOOP-14448:
-----------------------------------------

I don't know if we have to recreate the same behaviour here; the fact that SSEC doesn't work like the rest is a PITA -and it's why the SSEC test is in the sequential part of the test run. Maybe just skip the test suite if s3guard is on

> 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: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org