-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Make S3 custom query parameter optional #128043
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make S3 custom query parameter optional #128043
Conversation
Hi @DaveCTurner, I've created a changelog YAML for you. Note that since this PR is labelled |
Hi @DaveCTurner, I've updated the changelog YAML for you. Note that since this PR is labelled |
Today Elasticsearch will record the purpose for each request to S3 using a custom query parameter. This isn't believed to be necessary outside of the ECH/ECE/ECK/... managed services, and it adds rather a lot to the request logs, so with this commit we make the feature optional and disabled by default.
3fa7c30
to
6814d98
Compare
Hi @DaveCTurner, I've updated the changelog YAML for you. Note that since this PR is labelled |
This reverts commit 81cef8c.
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
Hi @DaveCTurner, I've updated the changelog YAML for you. Note that since this PR is labelled |
This reverts commit 6cca2b3.
Hi @DaveCTurner, I've updated the changelog YAML for you. Note that since this PR is labelled |
This reverts commit b9da53e.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
protected HttpHandler createHandler() { | ||
return new AssertingHandler(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we make AssertingHandler
delegate to the handler returned by super.createHandler()
so that we don't miss the fix from #102976?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure see 6b91e9b. It doesn't really matter here, the test fails either way.
return new AssertingHandler(); | ||
} | ||
}; | ||
httpFixture.apply(new Statement() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to stop the fixture explicitly especially when the test fails?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's handled within apply()
.
return; | ||
} | ||
} | ||
repoAnalysisStarted.set(true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's more readable to move this statement to be the last statement inside the if (repoAnalysisStarted.get() == false)
block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok see 0e58906
if (request.path().startsWith("/bucket/base_path_integration_tests/temp-analysis-")) { | ||
repoAnalysisStarted.set(true); | ||
} | ||
if (repoAnalysisStarted.get() == false) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With #126593, the s3 fixture now runs with multiple threads. Is there any racing concern with checking the atomic boolean? I guess it's probably not an issue since operations before repo analysis are all sequential?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the earlier operations relate to registering the repository and complete strictly before the start of repo analysis, regardless of concurrency in the handler.
Hi @DaveCTurner, I've updated the changelog YAML for you. Note that since this PR is labelled |
This reverts commit f38515d.
💔 Backport failed
You can use sqren/backport to manually backport by running |
Today Elasticsearch will record the purpose for each request to S3 using a custom query parameter[^1]. This isn't believed to be necessary outside of the ECH/ECE/ECK/... managed services, and it adds rather a lot to the request logs, so with this commit we make the feature optional and disabled by default. [^1]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/LogFormat.html#LogFormatCustom Backport of elastic#128043 to `9.0`
Today Elasticsearch will record the purpose for each request to S3 using a custom query parameter[^1]. This isn't believed to be necessary outside of the ECH/ECE/ECK/... managed services, and it adds rather a lot to the request logs, so with this commit we make the feature optional and disabled by default. Backport of elastic#128043 to `9.0` [^1]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/LogFormat.html#LogFormatCustom
Today Elasticsearch will record the purpose for each request to S3 using
a custom query parameter1. This isn't believed to be necessary outside of
the ECH/ECE/ECK/... managed services, and it adds rather a lot to the
request logs, so with this commit we make the feature optional and
disabled by default.
Footnotes
https://docs.aws.amazon.com/AmazonS3/latest/userguide/LogFormat.html#LogFormatCustom ↩