[jira] [Commented] (HADOOP-14734) add option to tag DDB table(s) created
[
https://issues.apache.org/jira/browse/HADOOP-14734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373543#comment-16373543
]
Abraham Fine commented on HADOOP-14734:
---
[~ste...@apache.org]-
* I think i fixed the checkstyle issue.
* I reverted dynamoDBDocumentClient to dynamoDB
* {{tagTable}} is called from {{createTable}}
* I believe I fixed the import ordering
* Can you expand on "test needs to skip when"?
* I don't think this change will make moving off of {{TestMetadataStore}} much
harder. I wanted to put this code in that class but tagging is not supported on
local dynamo instances, so I needed to create a new ITest. Unless I missed an
ITest there is no other appropriate place to put this test.
> add option to tag DDB table(s) created
> --
>
> Key: HADOOP-14734
> URL: https://issues.apache.org/jira/browse/HADOOP-14734
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 3.0.0-beta1
>Reporter: Steve Loughran
>Assignee: Abraham Fine
>Priority: Minor
> Attachments: HADOOP-14734-001.patch, HADOOP-14734-002.patch,
> HADOOP-14734-003.patch
>
>
> Many organisations have a "no untagged" resource policy; s3guard runs into
> this when a table is created untagged. If there's a strict "delete untagged
> resources" policy, the tables will go without warning.
> Proposed: we add an option which can be used to declare the tags for a table
> when created, use it in creation. No need to worry about updating/viewing
> tags, as the AWS console can do that
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-14734) add option to tag DDB table(s) created
[ https://issues.apache.org/jira/browse/HADOOP-14734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abraham Fine updated HADOOP-14734: -- Attachment: HADOOP-14734-003.patch > add option to tag DDB table(s) created > -- > > Key: HADOOP-14734 > URL: https://issues.apache.org/jira/browse/HADOOP-14734 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/s3 >Affects Versions: 3.0.0-beta1 >Reporter: Steve Loughran >Assignee: Abraham Fine >Priority: Minor > Attachments: HADOOP-14734-001.patch, HADOOP-14734-002.patch, > HADOOP-14734-003.patch > > > Many organisations have a "no untagged" resource policy; s3guard runs into > this when a table is created untagged. If there's a strict "delete untagged > resources" policy, the tables will go without warning. > Proposed: we add an option which can be used to declare the tags for a table > when created, use it in creation. No need to worry about updating/viewing > tags, as the AWS console can do that -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-14734) add option to tag DDB table(s) created
[
https://issues.apache.org/jira/browse/HADOOP-14734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16364643#comment-16364643
]
Abraham Fine commented on HADOOP-14734:
---
Looking at the remaining findbugs warning from:
[https://builds.apache.org/job/PreCommit-HADOOP-Build/14112/artifact/out/diff-checkstyle-hadoop-tools_hadoop-aws.txt]
{quote}./hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/s3guard/DynamoDBMetadataStore.java:251:
private DynamoDB createDynamoDB(Configuration conf, String s3Region):49:
'conf' hides a field. [HiddenField]
{quote}
This is strange to me since this does not appear to have changed between my
patch and trunk so I'm not sure why it was not present before.
> add option to tag DDB table(s) created
> --
>
> Key: HADOOP-14734
> URL: https://issues.apache.org/jira/browse/HADOOP-14734
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 3.0.0-beta1
>Reporter: Steve Loughran
>Assignee: Abraham Fine
>Priority: Minor
> Attachments: HADOOP-14734-001.patch, HADOOP-14734-002.patch
>
>
> Many organisations have a "no untagged" resource policy; s3guard runs into
> this when a table is created untagged. If there's a strict "delete untagged
> resources" policy, the tables will go without warning.
> Proposed: we add an option which can be used to declare the tags for a table
> when created, use it in creation. No need to worry about updating/viewing
> tags, as the AWS console can do that
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-14734) add option to tag DDB table(s) created
[ https://issues.apache.org/jira/browse/HADOOP-14734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abraham Fine updated HADOOP-14734: -- Attachment: HADOOP-14734-002.patch > add option to tag DDB table(s) created > -- > > Key: HADOOP-14734 > URL: https://issues.apache.org/jira/browse/HADOOP-14734 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/s3 >Affects Versions: 3.0.0-beta1 >Reporter: Steve Loughran >Assignee: Abraham Fine >Priority: Minor > Attachments: HADOOP-14734-001.patch, HADOOP-14734-002.patch > > > Many organisations have a "no untagged" resource policy; s3guard runs into > this when a table is created untagged. If there's a strict "delete untagged > resources" policy, the tables will go without warning. > Proposed: we add an option which can be used to declare the tags for a table > when created, use it in creation. No need to worry about updating/viewing > tags, as the AWS console can do that -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-14734) add option to tag DDB table(s) created
[ https://issues.apache.org/jira/browse/HADOOP-14734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363352#comment-16363352 ] Abraham Fine commented on HADOOP-14734: --- Fixed findbugs. Integration tests run against us-west-2 > add option to tag DDB table(s) created > -- > > Key: HADOOP-14734 > URL: https://issues.apache.org/jira/browse/HADOOP-14734 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/s3 >Affects Versions: 3.0.0-beta1 >Reporter: Steve Loughran >Assignee: Abraham Fine >Priority: Minor > Attachments: HADOOP-14734-001.patch, HADOOP-14734-002.patch > > > Many organisations have a "no untagged" resource policy; s3guard runs into > this when a table is created untagged. If there's a strict "delete untagged > resources" policy, the tables will go without warning. > Proposed: we add an option which can be used to declare the tags for a table > when created, use it in creation. No need to worry about updating/viewing > tags, as the AWS console can do that -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-14734) add option to tag DDB table(s) created
[
https://issues.apache.org/jira/browse/HADOOP-14734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363218#comment-16363218
]
Abraham Fine commented on HADOOP-14734:
---
A couple things to note about the patch:
* The document based Dynamo API does not appear to expose access to the
tagging API so we need to keep track of the {{AmazonDynamoDB}} object now.
* Each tag needs to be its own property in the config xml since commas are
allowed in the keys and values of a tag
* Tags are only added to a table when it is created and there is no retry logic
* The test must connect to "real DynamoDB" instead of the in-memory version we
use for some other tests, so it has its own class (since the in-memory version
does not appear to support tagging)
* The test assumes table creation privileges and that
{{S3GUARD_DDB_REGION_KEY}} is being provided
> add option to tag DDB table(s) created
> --
>
> Key: HADOOP-14734
> URL: https://issues.apache.org/jira/browse/HADOOP-14734
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 3.0.0-beta1
>Reporter: Steve Loughran
>Assignee: Abraham Fine
>Priority: Minor
> Attachments: HADOOP-14734-001.patch
>
>
> Many organisations have a "no untagged" resource policy; s3guard runs into
> this when a table is created untagged. If there's a strict "delete untagged
> resources" policy, the tables will go without warning.
> Proposed: we add an option which can be used to declare the tags for a table
> when created, use it in creation. No need to worry about updating/viewing
> tags, as the AWS console can do that
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-14734) add option to tag DDB table(s) created
[ https://issues.apache.org/jira/browse/HADOOP-14734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abraham Fine updated HADOOP-14734: -- Status: Patch Available (was: Open) > add option to tag DDB table(s) created > -- > > Key: HADOOP-14734 > URL: https://issues.apache.org/jira/browse/HADOOP-14734 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/s3 >Affects Versions: 3.0.0-beta1 >Reporter: Steve Loughran >Assignee: Abraham Fine >Priority: Minor > Attachments: HADOOP-14734-001.patch > > > Many organisations have a "no untagged" resource policy; s3guard runs into > this when a table is created untagged. If there's a strict "delete untagged > resources" policy, the tables will go without warning. > Proposed: we add an option which can be used to declare the tags for a table > when created, use it in creation. No need to worry about updating/viewing > tags, as the AWS console can do that -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Updated] (HADOOP-14734) add option to tag DDB table(s) created
[ https://issues.apache.org/jira/browse/HADOOP-14734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abraham Fine updated HADOOP-14734: -- Attachment: HADOOP-14734-001.patch > add option to tag DDB table(s) created > -- > > Key: HADOOP-14734 > URL: https://issues.apache.org/jira/browse/HADOOP-14734 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/s3 >Affects Versions: 3.0.0-beta1 >Reporter: Steve Loughran >Assignee: Abraham Fine >Priority: Minor > Attachments: HADOOP-14734-001.patch > > > Many organisations have a "no untagged" resource policy; s3guard runs into > this when a table is created untagged. If there's a strict "delete untagged > resources" policy, the tables will go without warning. > Proposed: we add an option which can be used to declare the tags for a table > when created, use it in creation. No need to worry about updating/viewing > tags, as the AWS console can do that -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-15140) S3guard mistakes root URI without / as non-absolute path
[
https://issues.apache.org/jira/browse/HADOOP-15140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16357706#comment-16357706
]
Abraham Fine commented on HADOOP-15140:
---
[~ste...@apache.org] What would a test that works consistently look like (as
the tests would also run on the local file system)?
> S3guard mistakes root URI without / as non-absolute path
>
>
> Key: HADOOP-15140
> URL: https://issues.apache.org/jira/browse/HADOOP-15140
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 3.0.0
>Reporter: Steve Loughran
>Assignee: Abraham Fine
>Priority: Major
>
> If you call {{getFileStatus("s3a://bucket")}} then S3Guard will throw an
> exception in putMetadata, as it mistakes the empty path for "non-absolute
> path"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-14109) improvements to S3GuardTool destroy command
[ https://issues.apache.org/jira/browse/HADOOP-14109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abraham Fine reassigned HADOOP-14109: - Assignee: Abraham Fine > improvements to S3GuardTool destroy command > --- > > Key: HADOOP-14109 > URL: https://issues.apache.org/jira/browse/HADOOP-14109 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/s3 >Affects Versions: 3.1.0 >Reporter: Steve Loughran >Assignee: Abraham Fine >Priority: Minor > > The S3GuardTool destroy operation initializes dynamoDB, and in doing so has > some issues > # if the version of the table is incompatible, init fails, so table isn't > deleteable > # if the system is configured to create the table on demand, then whenever > destroy is called for a table that doesn't exist, it gets created and then > destroyed. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-13980) S3Guard CLI: Add fsck check command
[ https://issues.apache.org/jira/browse/HADOOP-13980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abraham Fine reassigned HADOOP-13980: - Assignee: Abraham Fine (was: Aaron Fabbri) > S3Guard CLI: Add fsck check command > --- > > Key: HADOOP-13980 > URL: https://issues.apache.org/jira/browse/HADOOP-13980 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/s3 >Affects Versions: 3.0.0-beta1 >Reporter: Aaron Fabbri >Assignee: Abraham Fine >Priority: Major > > As discussed in HADOOP-13650, we want to add an S3Guard CLI command which > compares S3 with MetadataStore, and returns a failure status if any > invariants are violated. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HADOOP-15140) S3guard mistakes root URI without / as non-absolute path
[
https://issues.apache.org/jira/browse/HADOOP-15140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344201#comment-16344201
]
Abraham Fine edited comment on HADOOP-15140 at 1/30/18 10:36 PM:
-
[~ste...@apache.org] I went ahead and added two tests to
{{AbstractContractGetFileStatusTest}}:
{code:java}
@Test
public void testGetFileStatusRootURI() throws Throwable {
String fileSystemURI = getFileSystem().getUri().toString();
assertTrue("uri should not end with '/': " + fileSystemURI,
fileSystemURI.endsWith("//") || !fileSystemURI.endsWith("/"));
ContractTestUtils.assertIsDirectory(
getFileSystem().getFileStatus(new Path(fileSystemURI)));
}
@Test
public void testGetFileStatusRootFromChild() throws Throwable {
ContractTestUtils.assertIsDirectory(
getFileSystem().getFileStatus(new Path("/dir").getParent()));
}
{code}
These tests ran against S3, Azure, Azure Data Lake, and HDFS using: {{mvn test
-Dtest="**/\*ContractGetFileStatus\*" -DS3guard -fae
-Dmaven.test.failure.ignore=true}}
{{testGetFileStatusRootFromChild}} never appears to fail.
{{testGetFileStatusRootURI}} does on HDFS, S3, and Azure Data Lake (Azure
native passes). Local file systems also pass.
Here are the failures and their corresponding stack traces:
{code:java}
[INFO] Running org.apache.hadoop.fs.contract.hdfs.TestHDFSContractGetFileStatus
[ERROR] Tests run: 20, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.344
s <<< FAILURE! - in
org.apache.hadoop.fs.contract.hdfs.TestHDFSContractGetFileStatus
[ERROR]
testGetFileStatusRootURI(org.apache.hadoop.fs.contract.hdfs.TestHDFSContractGetFileStatus)
Time elapsed: 0.02 s <<< ERROR!
java.lang.IllegalArgumentException: Pathname from hdfs://localhost:63826 is
not a valid DFS filename.
at
org.apache.hadoop.hdfs.DistributedFileSystem.getPathName(DistributedFileSystem.java:242)
at
org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1568)
at
org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1565)
at
org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at
org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1580)
at
org.apache.hadoop.fs.contract.AbstractContractGetFileStatusTest.testGetFileStatusRootURI(AbstractContractGetFileStatusTest.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
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.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
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)
[INFO] Running org.apache.hadoop.fs.contract.s3a.ITestS3AContractGetFileStatus
[ERROR] Tests run: 20, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
113.029 s <<< FAILURE! - in
org.apache.hadoop.fs.contract.s3a.ITestS3AContractGetFileStatus
[ERROR]
testGetFileStatusRootURI(org.apache.hadoop.fs.contract.s3a.ITestS3AContractGetFileStatus)
Time elapsed: 1.27 s <<< ERROR!
java.lang.IllegalArgumentException: path must be absolute
at
com.google.common.base.Preconditions.checkArgument(Preconditions.java:88)
at
org.apache.hadoop.fs.s3a.s3guard.PathMetadata.(PathMetadata.java:68)
at
org.apache.hadoop.fs.s3a.s3guard.PathMetadata.(PathMetadata.java:60)
at
org.apache.hadoop.fs.s3a.s3guard.PathMetadata.(PathMetadata.java:56)
at
org.apache.hadoop.fs.s3a.s3guard.S3Guard.putAndReturn(S3Guard.java:149)
at
org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2130)
at
org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2070)
at
org.apache.hadoop.fs.contract.AbstractContractGetFileStatusTest.testGetFileStatusRootURI(AbstractContractGetFileStatusTest.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Delega
[jira] [Commented] (HADOOP-15140) S3guard mistakes root URI without / as non-absolute path
[
https://issues.apache.org/jira/browse/HADOOP-15140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344201#comment-16344201
]
Abraham Fine commented on HADOOP-15140:
---
[~ste...@apache.org] I went ahead and added two tests to
{{AbstractContractGetFileStatusTest}}:
{code:java}
@Test
public void testGetFileStatusRootURI() throws Throwable {
String fileSystemURI = getFileSystem().getUri().toString();
assertTrue("uri should not end with '/': " + fileSystemURI,
fileSystemURI.endsWith("//") || !fileSystemURI.endsWith("/"));
ContractTestUtils.assertIsDirectory(
getFileSystem().getFileStatus(new Path(fileSystemURI)));
}
@Test
public void testGetFileStatusRootFromChild() throws Throwable {
ContractTestUtils.assertIsDirectory(
getFileSystem().getFileStatus(new Path("/dir").getParent()));
}
{code}
These tests ran against S3, Azure, Azure Data Lake, and HDFS using: {{mvn test
-Dtest="**/*ContractGetFileStatus*" -DS3guard -fae
-Dmaven.test.failure.ignore=true}}
{{testGetFileStatusRootFromChild}} never appears to fail.
{{testGetFileStatusRootURI}} does on HDFS, S3, and Azure Data Lake (Azure
native passes). Local file systems also pass.
Here are the failures and their corresponding stack traces:
{code:java}
[INFO] Running org.apache.hadoop.fs.contract.hdfs.TestHDFSContractGetFileStatus
[ERROR] Tests run: 20, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.344
s <<< FAILURE! - in
org.apache.hadoop.fs.contract.hdfs.TestHDFSContractGetFileStatus
[ERROR]
testGetFileStatusRootURI(org.apache.hadoop.fs.contract.hdfs.TestHDFSContractGetFileStatus)
Time elapsed: 0.02 s <<< ERROR!
java.lang.IllegalArgumentException: Pathname from hdfs://localhost:63826 is
not a valid DFS filename.
at
org.apache.hadoop.hdfs.DistributedFileSystem.getPathName(DistributedFileSystem.java:242)
at
org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1568)
at
org.apache.hadoop.hdfs.DistributedFileSystem$29.doCall(DistributedFileSystem.java:1565)
at
org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at
org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1580)
at
org.apache.hadoop.fs.contract.AbstractContractGetFileStatusTest.testGetFileStatusRootURI(AbstractContractGetFileStatusTest.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
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.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
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)
[INFO] Running org.apache.hadoop.fs.contract.s3a.ITestS3AContractGetFileStatus
[ERROR] Tests run: 20, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
113.029 s <<< FAILURE! - in
org.apache.hadoop.fs.contract.s3a.ITestS3AContractGetFileStatus
[ERROR]
testGetFileStatusRootURI(org.apache.hadoop.fs.contract.s3a.ITestS3AContractGetFileStatus)
Time elapsed: 1.27 s <<< ERROR!
java.lang.IllegalArgumentException: path must be absolute
at
com.google.common.base.Preconditions.checkArgument(Preconditions.java:88)
at
org.apache.hadoop.fs.s3a.s3guard.PathMetadata.(PathMetadata.java:68)
at
org.apache.hadoop.fs.s3a.s3guard.PathMetadata.(PathMetadata.java:60)
at
org.apache.hadoop.fs.s3a.s3guard.PathMetadata.(PathMetadata.java:56)
at
org.apache.hadoop.fs.s3a.s3guard.S3Guard.putAndReturn(S3Guard.java:149)
at
org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2130)
at
org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2070)
at
org.apache.hadoop.fs.contract.AbstractContractGetFileStatusTest.testGetFileStatusRootURI(AbstractContractGetFileStatusTest.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.
[jira] [Commented] (HADOOP-14757) S3AFileSystem.innerRename() to size metadatastore lists better
[
https://issues.apache.org/jira/browse/HADOOP-14757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16339590#comment-16339590
]
Abraham Fine commented on HADOOP-14757:
---
[~ste...@apache.org] I'm not sure how much value we would get from doing
something like this relative to the amount of work involved. The single file
copy case is trivial but the second case gets a bit more complicated.
My guess is that this ticket refers to the {{dstMetas}} list created in
{{innerRename}}.
We have multiple layers of iterators in play here and we would need to bubble
up a guess for the size size of the list which could be quite ugly.
I think another possible option would be to use a Linked List since we do not
do any random access but any benchmarks I found for ArrayList vs LinkedList
performance showed minimal to know gains and occasional slowdowns. I think the
best action here may be no action. What do you think?
> S3AFileSystem.innerRename() to size metadatastore lists better
> --
>
> Key: HADOOP-14757
> URL: https://issues.apache.org/jira/browse/HADOOP-14757
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 3.0.0-beta1
>Reporter: Steve Loughran
>Assignee: Abraham Fine
>Priority: Minor
> Fix For: 3.1.0
>
>
> In {{S3AFileSystem.innerRename()}}, various ArrayLists are created to track
> paths to update; these are created with the default size. It could/should be
> possible to allocate better, so avoid expensive array growth & copy
> operations while iterating through the list of entries.
> # for a single file copy, sizes == 1
> # for a recursive copy, the outcome of the first real LIST will either
> provide the actual size, or, if the list == the max response, a very large
> minimum size.
> For #2, we'd need to get the hint of iterable length rather than just iterate
> through...some interface {{{IterableLength.expectedMinimumSize()}} could do
> that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-14734) add option to tag DDB table(s) created
[ https://issues.apache.org/jira/browse/HADOOP-14734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abraham Fine reassigned HADOOP-14734: - Assignee: Abraham Fine > add option to tag DDB table(s) created > -- > > Key: HADOOP-14734 > URL: https://issues.apache.org/jira/browse/HADOOP-14734 > Project: Hadoop Common > Issue Type: Sub-task > Components: fs/s3 >Affects Versions: 3.0.0-beta1 >Reporter: Steve Loughran >Assignee: Abraham Fine >Priority: Minor > > Many organisations have a "no untagged" resource policy; s3guard runs into > this when a table is created untagged. If there's a strict "delete untagged > resources" policy, the tables will go without warning. > Proposed: we add an option which can be used to declare the tags for a table > when created, use it in creation. No need to worry about updating/viewing > tags, as the AWS console can do that -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Resolved] (HADOOP-14577) ITestS3AInconsistency.testGetFileStatus failing in -DS3guard test runs
[
https://issues.apache.org/jira/browse/HADOOP-14577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abraham Fine resolved HADOOP-14577.
---
Resolution: Cannot Reproduce
> ITestS3AInconsistency.testGetFileStatus failing in -DS3guard test runs
> --
>
> Key: HADOOP-14577
> URL: https://issues.apache.org/jira/browse/HADOOP-14577
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3, test
>Affects Versions: 3.0.0-beta1
>Reporter: Sean Mackrory
>Assignee: Abraham Fine
>Priority: Minor
>
> This test is failing for me when run individually or in parallel (with
> -Ds3guard). Even if I revert back to the commit that introduced it. I thought
> I had successful test runs on that before and haven't changed anything in my
> test configuration.
> {code}Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.671
> sec <<< FAILURE! - in org.apache.hadoop.fs.s3a.ITestS3AInconsistency
> testGetFileStatus(org.apache.hadoop.fs.s3a.ITestS3AInconsistency) Time
> elapsed: 4.475 sec <<< FAILURE!
> java.lang.AssertionError: S3Guard failed to list parent of inconsistent child.
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.hadoop.fs.s3a.ITestS3AInconsistency.testGetFileStatus(ITestS3AInconsistency.java:83){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-14757) S3AFileSystem.innerRename() to size metadatastore lists better
[
https://issues.apache.org/jira/browse/HADOOP-14757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abraham Fine reassigned HADOOP-14757:
-
Assignee: Abraham Fine
> S3AFileSystem.innerRename() to size metadatastore lists better
> --
>
> Key: HADOOP-14757
> URL: https://issues.apache.org/jira/browse/HADOOP-14757
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 3.0.0-beta1
>Reporter: Steve Loughran
>Assignee: Abraham Fine
>Priority: Minor
> Fix For: 3.1.0
>
>
> In {{S3AFileSystem.innerRename()}}, various ArrayLists are created to track
> paths to update; these are created with the default size. It could/should be
> possible to allocate better, so avoid expensive array growth & copy
> operations while iterating through the list of entries.
> # for a single file copy, sizes == 1
> # for a recursive copy, the outcome of the first real LIST will either
> provide the actual size, or, if the list == the max response, a very large
> minimum size.
> For #2, we'd need to get the hint of iterable length rather than just iterate
> through...some interface {{{IterableLength.expectedMinimumSize()}} could do
> that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-14577) ITestS3AInconsistency.testGetFileStatus failing in -DS3guard test runs
[
https://issues.apache.org/jira/browse/HADOOP-14577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16331009#comment-16331009
]
Abraham Fine commented on HADOOP-14577:
---
[~mackrorysd] [~ste...@apache.org] I have been unable to replicate this on the
latest trunk. Is this still an issue?
> ITestS3AInconsistency.testGetFileStatus failing in -DS3guard test runs
> --
>
> Key: HADOOP-14577
> URL: https://issues.apache.org/jira/browse/HADOOP-14577
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3, test
>Affects Versions: 3.0.0-beta1
>Reporter: Sean Mackrory
>Assignee: Abraham Fine
>Priority: Minor
>
> This test is failing for me when run individually or in parallel (with
> -Ds3guard). Even if I revert back to the commit that introduced it. I thought
> I had successful test runs on that before and haven't changed anything in my
> test configuration.
> {code}Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.671
> sec <<< FAILURE! - in org.apache.hadoop.fs.s3a.ITestS3AInconsistency
> testGetFileStatus(org.apache.hadoop.fs.s3a.ITestS3AInconsistency) Time
> elapsed: 4.475 sec <<< FAILURE!
> java.lang.AssertionError: S3Guard failed to list parent of inconsistent child.
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.hadoop.fs.s3a.ITestS3AInconsistency.testGetFileStatus(ITestS3AInconsistency.java:83){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-14577) ITestS3AInconsistency.testGetFileStatus failing in -DS3guard test runs
[
https://issues.apache.org/jira/browse/HADOOP-14577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abraham Fine reassigned HADOOP-14577:
-
Assignee: Abraham Fine
> ITestS3AInconsistency.testGetFileStatus failing in -DS3guard test runs
> --
>
> Key: HADOOP-14577
> URL: https://issues.apache.org/jira/browse/HADOOP-14577
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3, test
>Affects Versions: 3.0.0-beta1
>Reporter: Sean Mackrory
>Assignee: Abraham Fine
>Priority: Minor
>
> This test is failing for me when run individually or in parallel (with
> -Ds3guard). Even if I revert back to the commit that introduced it. I thought
> I had successful test runs on that before and haven't changed anything in my
> test configuration.
> {code}Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.671
> sec <<< FAILURE! - in org.apache.hadoop.fs.s3a.ITestS3AInconsistency
> testGetFileStatus(org.apache.hadoop.fs.s3a.ITestS3AInconsistency) Time
> elapsed: 4.475 sec <<< FAILURE!
> java.lang.AssertionError: S3Guard failed to list parent of inconsistent child.
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.hadoop.fs.s3a.ITestS3AInconsistency.testGetFileStatus(ITestS3AInconsistency.java:83){code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HADOOP-15076) Enhance s3a troubleshooting docs, add perf section
[
https://issues.apache.org/jira/browse/HADOOP-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323239#comment-16323239
]
Abraham Fine edited comment on HADOOP-15076 at 1/11/18 11:49 PM:
-
I'm new to this codebase so I think I was able to point out a few parts of the
documentation that may be confusing to new users.
h3. performance.md
* Would it be possible to change the introduction setting from two sequential
lists to a table? That may make it easier to compare S3 and HDFS.
* {{list files a lot. This includes the setup of all queries agains data:}}
typo in agains
* {{The MapReduce `FileOutputCommitter`. This also used by Apache Spark.}} I'm
not sure what this sentence is trying to express
* {{Your problem may appear to be performance, but really it is that the commit
protocol is both slow and unreliable}} Isn't the commit protocol being slow
part of "performance"? Can this be rephrased?
* {{This is leads to maximum read throughput}} "This will lead to..."?
* Perhaps describe the {{random}} policy before {{normal}} as one needs to
understand {{random}} before understanding {{normal}}.
* {{may consume large amounts of resources if each query is working with a
different set of s3 buckets}} Why wouldn't a large amount of resources be
consumed if working with the same set of s3 buckets?
* {{When uploading data, it is uploaded in blocks set by the option}} Consider
changing to "Data is uploaded in blocks set by the option..."
* Extra newline on 451
h3. troubleshooting_s3a.md
* {{Whatever problem you have, changing the AWS SDK version will not fix
things, only change the stack traces you see.}} Again, I'm new here so I'm not
sure about the history of this issue but this section seems a little heavy
handed to me. Does amazon never release "bug fix" versions of their client that
are API compatible? How can we make this statement with such certainty?
was (Author: abrahamfine):
I'm new to this codebase so I think I was able to point out a few parts of the
documentation that may be confusing to new users.
h3. performance.md
* Would it be possible to change the introduction setting from two sequential
lists to a table? That may make it easier to compare S3 and HDFS.
* {{list files a lot. This includes the setup of all queries agains data:}}
typo in agains
* {{The MapReduce `FileOutputCommitter`. This also used by Apache Spark.}} I'm
not sure what this sentence is trying to express
* {{Your problem may appear to be performance, but really it is that the commit
protocol is both slow and unreliable}} Isn't the commit protocol being slow
part of "performance"? Can this be rephrased?
* {{This is leads to maximum read throughput}} "This will lead to..."?
* Perhaps describe the {{random}} policy before {{normal}} as one needs to
understand {{random}} before understanding {{normal}}.
* {{may consume large amounts of resources if each query is working with a
different set of s3 buckets}} Why wouldn't a large amount of resources be
consumed if working with the same set of s3 buckets?
* {{When uploading data, it is uploaded in blocks set by the option}} Consider
changing to "Data is uploaded in blocks set by the option..."
* Extra newline on 451
h3. troubleshooting_s3a.md
* {{Whatever problem you have, changing the AWS SDK version will not fix
things, only change the stack traces you see.}} Again, I'm new here so I'm not
sure about the history of this issue but this section seems a little heavy
handed to me. Does amazon never release "bug fix" versions of their client that
are API compatible? How can we make this statement with such certainty?
*
> Enhance s3a troubleshooting docs, add perf section
> --
>
> Key: HADOOP-15076
> URL: https://issues.apache.org/jira/browse/HADOOP-15076
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: documentation, fs/s3
>Affects Versions: 2.8.2
>Reporter: Steve Loughran
>Assignee: Abraham Fine
> Attachments: HADOOP-15076-001.patch, HADOOP-15076-002.patch,
> HADOOP-15076-003.patch, HADOOP-15076-004.patch
>
>
> A recurrent theme in s3a-related JIRAs, support calls etc is "tried upgrading
> the AWS SDK JAR and then I got the error ...". We know here "don't do that",
> but its not something immediately obvious to lots of downstream users who
> want to be able to drop in the new JAR to fix things/add new features
> We need to spell this out quite clearlyi "you cannot safely expect to do
> this. If you want to upgrade the SDK, you will need to rebuild the whole of
> hadoop-aws with the maven POM updated to the latest version, ideally
> rerunning all the tests to make sure something hasn't broken.
> Maybe near the top of the index.md file, along with "never share your AWS
> credentials
[jira] [Commented] (HADOOP-15076) Enhance s3a troubleshooting docs, add perf section
[
https://issues.apache.org/jira/browse/HADOOP-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16323239#comment-16323239
]
Abraham Fine commented on HADOOP-15076:
---
I'm new to this codebase so I think I was able to point out a few parts of the
documentation that may be confusing to new users.
h3. performance.md
* Would it be possible to change the introduction setting from two sequential
lists to a table? That may make it easier to compare S3 and HDFS.
* {{list files a lot. This includes the setup of all queries agains data:}}
typo in agains
* {{The MapReduce `FileOutputCommitter`. This also used by Apache Spark.}} I'm
not sure what this sentence is trying to express
* {{Your problem may appear to be performance, but really it is that the commit
protocol is both slow and unreliable}} Isn't the commit protocol being slow
part of "performance"? Can this be rephrased?
* {{This is leads to maximum read throughput}} "This will lead to..."?
* Perhaps describe the {{random}} policy before {{normal}} as one needs to
understand {{random}} before understanding {{normal}}.
* {{may consume large amounts of resources if each query is working with a
different set of s3 buckets}} Why wouldn't a large amount of resources be
consumed if working with the same set of s3 buckets?
* {{When uploading data, it is uploaded in blocks set by the option}} Consider
changing to "Data is uploaded in blocks set by the option..."
* Extra newline on 451
h3. troubleshooting_s3a.md
* {{Whatever problem you have, changing the AWS SDK version will not fix
things, only change the stack traces you see.}} Again, I'm new here so I'm not
sure about the history of this issue but this section seems a little heavy
handed to me. Does amazon never release "bug fix" versions of their client that
are API compatible? How can we make this statement with such certainty?
*
> Enhance s3a troubleshooting docs, add perf section
> --
>
> Key: HADOOP-15076
> URL: https://issues.apache.org/jira/browse/HADOOP-15076
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: documentation, fs/s3
>Affects Versions: 2.8.2
>Reporter: Steve Loughran
>Assignee: Abraham Fine
> Attachments: HADOOP-15076-001.patch, HADOOP-15076-002.patch,
> HADOOP-15076-003.patch, HADOOP-15076-004.patch
>
>
> A recurrent theme in s3a-related JIRAs, support calls etc is "tried upgrading
> the AWS SDK JAR and then I got the error ...". We know here "don't do that",
> but its not something immediately obvious to lots of downstream users who
> want to be able to drop in the new JAR to fix things/add new features
> We need to spell this out quite clearlyi "you cannot safely expect to do
> this. If you want to upgrade the SDK, you will need to rebuild the whole of
> hadoop-aws with the maven POM updated to the latest version, ideally
> rerunning all the tests to make sure something hasn't broken.
> Maybe near the top of the index.md file, along with "never share your AWS
> credentials with anyone"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-15140) S3guard mistakes root URI without / as non-absolute path
[
https://issues.apache.org/jira/browse/HADOOP-15140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322921#comment-16322921
]
Abraham Fine commented on HADOOP-15140:
---
[~steve_l] I wanted to confirm what the expected behavior should be here before
I submit a patch. Let me know if you agree.
The first thing we want to do here is make sure that in the case when a path is
actually "non-absolute", we log the path in the error message.
Secondly, we need to determine how to handle {{"s3a://bucket"}}. My
understanding is that since we do not have a {{/}} at the end of the URI, this
is a URI without a path ({{bucket}} is the authority) and an exception should
be thrown. I think the {{fileStatus path must be non-null}} message would be
appropriate. Or is it the case that we want to treat {{"s3a://bucket"}} like
{{"s3a://bucket/"}} and not throw an exception?
> S3guard mistakes root URI without / as non-absolute path
>
>
> Key: HADOOP-15140
> URL: https://issues.apache.org/jira/browse/HADOOP-15140
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 3.0.0
>Reporter: Steve Loughran
>Assignee: Abraham Fine
>
> If you call {{getFileStatus("s3a://bucket")}} then S3Guard will throw an
> exception in putMetadata, as it mistakes the empty path for "non-absolute
> path"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-15140) S3guard mistakes root URI without / as non-absolute path
[
https://issues.apache.org/jira/browse/HADOOP-15140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abraham Fine reassigned HADOOP-15140:
-
Assignee: Abraham Fine
> S3guard mistakes root URI without / as non-absolute path
>
>
> Key: HADOOP-15140
> URL: https://issues.apache.org/jira/browse/HADOOP-15140
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
>Affects Versions: 3.0.0
>Reporter: Steve Loughran
>Assignee: Abraham Fine
>
> If you call {{getFileStatus("s3a://bucket")}} then S3Guard will throw an
> exception in putMetadata, as it mistakes the empty path for "non-absolute
> path"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Assigned] (HADOOP-15076) s3a troubleshooting to add "things don't work after I dropped in a new AWS SDK JAR"
[ https://issues.apache.org/jira/browse/HADOOP-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abraham Fine reassigned HADOOP-15076: - Assignee: Abraham Fine > s3a troubleshooting to add "things don't work after I dropped in a new AWS > SDK JAR" > --- > > Key: HADOOP-15076 > URL: https://issues.apache.org/jira/browse/HADOOP-15076 > Project: Hadoop Common > Issue Type: Sub-task > Components: documentation, fs/s3 >Affects Versions: 2.8.2 >Reporter: Steve Loughran >Assignee: Abraham Fine > > A recurrent theme in s3a-related JIRAs, support calls etc is "tried upgrading > the AWS SDK JAR and then I got the error ...". We know here "don't do that", > but its not something immediately obvious to lots of downstream users who > want to be able to drop in the new JAR to fix things/add new features > We need to spell this out quite clearlyi "you cannot safely expect to do > this. If you want to upgrade the SDK, you will need to rebuild the whole of > hadoop-aws with the maven POM updated to the latest version, ideally > rerunning all the tests to make sure something hasn't broken. > Maybe near the top of the index.md file, along with "never share your AWS > credentials with anyone" -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
