-
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
Convert flaky yml tests to EsRestTestCases #63634
Conversation
This use case is covered in the `TimeseriesLifecycleActionIT` in several tests like: `testMoveToAllocateStep` or `testMoveToRolloverStep`
The yml "Test Invalid Move To Step With Invalid Next Step" worked based on assuming the current step is a particular one. As we can't control the timing of ILM and we can't busy assert in yml test, this converts the test to a java test and makes use of `assertBusy`
This converts the explain lifecycle yml tests that depende on ILM having run at least once to a java integration test that makes use of `assertBusy`.
Pinging @elastic/es-core-features (:Core/Features/ILM+SLM) |
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, I left some really minor comments, thanks!
@@ -228,6 +242,15 @@ public static void createIndexWithSettings(RestClient client, String index, Stri | |||
ensureGreen(index); | |||
} | |||
|
|||
public static void createIndexWithSettingsNoAlias(RestClient client, String index, Settings.Builder settings) 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.
Maybe instead of adding a helper (it's also strange that it's called "NoAlias" since the default should always be no alias), we should change the other createIndexWithSettings
to make the alias @Nullable
?
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've renamed the method createIndexWithSettings
(c399088) with signature:
public static void createIndexWithSettings(RestClient client, String index, Settings.Builder settings) throws IOException {
I think piggybacking this use case on the helper that has the alias
and useWriteIndex
parameters by making both @Nullable
over complicates the logic (and we'd end up passing 2 null
parameters).
What do you think?
public static void createIndexWithSettingsNoAlias(RestClient client, String index, Settings.Builder settings) throws IOException { | ||
Request request = new Request("PUT", "/" + index); | ||
request.setJsonEntity("{\n \"settings\": " + Strings.toString(settings.build()) | ||
+ "}"); |
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.
Super minor, but probably no need for a newline here :)
assertManagedIndex(explain.get(secondIndex)); | ||
assertUnmanagedIndex(explain.get(unmanagedIndex)); | ||
|
||
Map<String, Object> explainIndexWithMissingPolicy = explain.get(indexWithMissingPolicy); |
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 we could probably put this one is a second assertBusy
so that we don't end up doing two explains when we only need to do one
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.
There's only one explain API call in this assertBusy. I believe it's ok to leave it in one assertBusy
call.
@elasticmachine update branch |
The yml "Test Invalid Move To Step With Invalid Next Step" worked based on assuming the current step is a particular one. As we can't control the timing of ILM and we can't busy assert in yml test, this converts the test to a java test and makes use of `assertBusy` This converts the explain lifecycle yml tests that depende on ILM having run at least once to a java integration test that makes use of `assertBusy`. (cherry picked from commit 6afd042) Signed-off-by: Andrei Dan <andrei.dan@elastic.co>
The yml "Test Invalid Move To Step With Invalid Next Step" worked based on assuming the current step is a particular one. As we can't control the timing of ILM and we can't busy assert in yml test, this converts the test to a java test and makes use of `assertBusy` This converts the explain lifecycle yml tests that depende on ILM having run at least once to a java integration test that makes use of `assertBusy`. (cherry picked from commit 6afd042) Signed-off-by: Andrei Dan <andrei.dan@elastic.co>
The yml "Test Invalid Move To Step With Invalid Next Step" worked based on assuming the current step is a particular one. As we can't control the timing of ILM and we can't busy assert in yml test, this converts the test to a java test and makes use of `assertBusy` This converts the explain lifecycle yml tests that depende on ILM having run at least once to a java integration test that makes use of `assertBusy`. (cherry picked from commit 6afd042) Signed-off-by: Andrei Dan <andrei.dan@elastic.co>
The yml "Test Invalid Move To Step With Invalid Next Step" worked based on assuming the current step is a particular one. As we can't control the timing of ILM and we can't busy assert in yml test, this converts the test to a java test and makes use of `assertBusy` This converts the explain lifecycle yml tests that depende on ILM having run at least once to a java integration test that makes use of `assertBusy`. (cherry picked from commit 6afd042) Signed-off-by: Andrei Dan <andrei.dan@elastic.co>
We've had several failures in the yml ILM tests because ILM doesn't run in a deterministic way
and we can't wait for it to run in the yml test. The latest failure,
field [indices.another_index.phase] is null
,is another symptom.
This PR converts the ILM yml tests that rely on ILM having run (eg. successful explain api
output tests for managed indices, valid and invalid move to step api tests that specify the
correct current step) into
ESRestTestCase
tests that make use of theassertBusy
primitive.Resolves #47275
Relates to #53488