You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Sean Mackrory (JIRA)" <ji...@apache.org> on 2017/06/06 23:55:18 UTC

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

     [ https://issues.apache.org/jira/browse/HADOOP-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sean Mackrory updated HADOOP-14448:
-----------------------------------
    Attachment: HADOOP-14448-HADOOP-13345.001.patch

Attaching patch that skips the tests that usually only throw AccessDeniedException because of metadata operations that we short-circuit when S3Guard is enabled.

While testing this, I've seen testCreateFileThenMoveWithDifferentSSECKey and testCreateFileThenReadWithDifferentSSECKey fail (in the sense that they fail to throw an exception) both with and without S3Guard. So it seems unrelated to S3Guard, but I'm wondering if we're actually hitting a consistency issue, where there's no object, or there's an old unencrypted object or something and so the test sequence doesn't throw an AccessDeniedException? Just thinking out loud.

But this patch addresses what appears to be the only S3Guard-related part of the problem.

> 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
>         Attachments: HADOOP-14448-HADOOP-13345.001.patch
>
>
> 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