-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Migrate repository-s3
YAML tests to Java REST tests
#117628
Migrate repository-s3
YAML tests to Java REST tests
#117628
Conversation
f727f81
to
b32777e
Compare
Today these YAML tests rely on a bunch of rather complex setup organised by Gradle, and contain lots of duplication and coincident strings, mostly because that was the only way to achieve what we wanted before we could orchestrate test clusters and fixtures directly from Java test suites. We're not actually running the YAML tests in ways that take advantage of their YAMLness (e.g. in mixed-version clusters, or from other client libraries). This commit replaces these tests with Java REST tests which enormously simplifies this area of code. Relates ES-9984
b32777e
to
5ff3d75
Compare
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
In case it helps with reviews: there's quite some noise in this PR but the main change here is to drop the essentially-identical There's a couple of other changes here, namely to expose the bucket name in the MinIO fixture (which was previously hard-coded as |
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, nice tidy up
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
The REST version is much cleaner. One question that I have is whether the client team (or other teams) depends on the existing yaml tests. I seem to remember they are used for intergration tests. Probably not an issue since we still have 10_basic and some of the 20. The rest is mostly duplicated for different type of credentials. A heads-up ping to the client team could still be helpful.
|
||
@Before | ||
public void skipIfFips() { | ||
assumeFalse("doesn't work in a FIPS JVM, but that's ok", inFipsJvm()); |
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.
Is this still necessary? The existing yaml tests do not seem to need it. But we can also tackle this in a separate PR.
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 you're right now that you've fixed the fixtures to make long enough keys in #117675. Removed.
protected abstract String getClientName(); | ||
|
||
protected static String getIdentifierPrefix(String testSuiteName) { | ||
return testSuiteName + "-" + Integer.toString(Murmur3HashFunction.hash(testSuiteName + System.getProperty("tests.seed")), 16) + "-"; |
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.
This is in a method. I think we can just use the usual randomIdentifier
and friends instead of performing hash manually?
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.
Unfortunately not, this is called when initializing some static fields in the test suite classes, which happens too early to use randomIdentifier()
.
public void onBlobStoreClose() { | ||
releaseCachedClients(); | ||
} | ||
|
||
public void close() throws IOException { |
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.
Nit: missing @Override
here.
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.
++ thanks
// The AWS STS SDK requires the role and session names to be set. We can verify that they are sent to S3S in the | ||
// S3HttpFixtureWithSTS fixture |
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.
Is this comment no longer relevant?
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.
It was never correct - we don't ever actually send any requests to S3 in this test suite, we're just doing some basic initialization to make sure that ES doesn't encounter any problems with e.g. the security manager.
bucket: @permanent_bucket@ | ||
bucket: bucket | ||
client: integration_test_permanent | ||
base_path: "@permanent_base_path@" | ||
base_path: base_path_integration_tests |
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.
Just making sure I understand this: These yaml tests do not run against 3rd party services so that passing these variables from the build.gradle file was never really useful for them. So we can just hard code them?
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.
Correct.
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.
LGTM3
💔 Backport failed
You can use sqren/backport to manually backport by running |
Backport pending on backport of #117749 first. |
Today these YAML tests rely on a bunch of rather complex setup organised by Gradle, and contain lots of duplication and coincident strings, mostly because that was the only way to achieve what we wanted before we could orchestrate test clusters and fixtures directly from Java test suites. We're not actually running the YAML tests in ways that take advantage of their YAMLness (e.g. in mixed-version clusters, or from other client libraries). This commit replaces these tests with Java REST tests which enormously simplifies this area of code. Relates ES-9984 Backport of elastic#117628 to 8.x
Today these YAML tests rely on a bunch of rather complex setup organised by Gradle, and contain lots of duplication and coincident strings, mostly because that was the only way to achieve what we wanted before we could orchestrate test clusters and fixtures directly from Java test suites. We're not actually running the YAML tests in ways that take advantage of their YAMLness (e.g. in mixed-version clusters, or from other client libraries). This commit replaces these tests with Java REST tests which enormously simplifies this area of code. Relates ES-9984 Backport of #117628 to 8.x
Today these YAML tests rely on a bunch of rather complex setup organised
by Gradle, and contain lots of duplication and coincident strings,
mostly because that was the only way to achieve what we wanted before we
could orchestrate test clusters and fixtures directly from Java test
suites. We're not actually running the YAML tests in ways that take
advantage of their YAMLness (e.g. in mixed-version clusters, or from
other client libraries).
This commit replaces these tests with Java REST tests which enormously
simplifies this area of code.
Relates ES-9984