[
https://issues.apache.org/jira/browse/HADOOP-14476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035691#comment-16035691
]
Aaron Fabbri commented on HADOOP-14476:
---------------------------------------
I started on this but shout if you wanted to work on it [[email protected]].
I'd like to make it configurable but I'm not sure if we want to pollute the
config space with failure injection stuff. Maybe leave the values out of
core-default.xml and just document them in testing.md? Thoughts?
I'm currently thinking of adding a couple of knobs.
1. Delay time in milliseconds (how long the inconsistency lasts).
2. Substring for matching paths to be delayed.
3. A probability for random failure injection.
> make InconsistentAmazonS3Client usable in downstream tests
> ----------------------------------------------------------
>
> Key: HADOOP-14476
> URL: https://issues.apache.org/jira/browse/HADOOP-14476
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3, test
> Affects Versions: HADOOP-13345
> Reporter: Steve Loughran
> Assignee: Aaron Fabbri
>
> It's important for downstream apps to be able to verify that s3guard works by
> making the AWS client inconsistent (so demonstrate problems), then turn
> s3guard on to verify that they go away.
> This can be done by exposing the {{InconsistentAmazonS3Client}}
> # move the factory to the production source
> # make delay configurable for when you want a really long delay
> # have factory code log @ warn when a non-default factory is used.
> # mention in s3a testing.md
> I think we could look at the name of the option,
> {{fs.s3a.s3.client.factory.impl}} too. I'd like something which has
> "internal" in it, and without the duplication of s3a.s3
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
