Make S3 custom query parameter optional#128043
Make S3 custom query parameter optional#128043elasticsearchmachine merged 13 commits intoelastic:mainfrom
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.
| protected HttpHandler createHandler() { | ||
| return new AssertingHandler(); | ||
| } |
There was a problem hiding this comment.
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.
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.
Do we need to stop the fixture explicitly especially when the test fails?
There was a problem hiding this comment.
That's handled within apply().
| return; | ||
| } | ||
| } | ||
| repoAnalysisStarted.set(true); |
There was a problem hiding this comment.
I think it's more readable to move this statement to be the last statement inside the if (repoAnalysisStarted.get() == false) block.
| 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.
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.
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 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 `8.19` [^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 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 `8.18` [^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 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 `8.17` [^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 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 #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 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 #128043 to `8.17` [^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 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 #128043 to `8.18` [^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 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 #128043 to `8.19` [^1]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/LogFormat.html#LogFormatCustom
* Adapt to S3 custom query parameter optionality Serverless counterpart of elastic#128043 * OBS uses `backup` client * Update submodule * Set `default` parameter too --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co>
* Adapt to S3 custom query parameter optionality Serverless counterpart of elastic#128043 * OBS uses `backup` client * Update submodule * Set `default` parameter too --------- Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co>
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 ↩