-
Notifications
You must be signed in to change notification settings - Fork 1.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
Add indexing,search BwC tests for type mapping removal changes #2601
Add indexing,search BwC tests for type mapping removal changes #2601
Conversation
Signed-off-by: Kunal Kotwani <[email protected]>
qa/rolling-upgrade/src/test/java/org/opensearch/upgrades/IndexingIT.java
Outdated
Show resolved
Hide resolved
❌ Gradle Check failure f53b5cdc8ba9453bb7d558bf009c446adfeba7a4 |
Gradle check failure. The resp object from _search action seems to be null
Failure stacktrace.
|
It does pass on my local. Taking a look at this. |
Signed-off-by: Kunal Kotwani <[email protected]>
f53b5cd
to
92bc227
Compare
|
Failure doesn't belong to code changes. Re-firing |
start gradle check |
Another unrelated test failure -
|
start gradle check |
There is already issue opened for |
Updated the code for failing test:
|
❌ Gradle Check failure 88d92c887669d8a3e5660d0d49e7e5d6720f61b2 |
88d92c8
to
90a3fdd
Compare
❌ Gradle Check failure 90a3fdd6f5798b694e37cf653fdf9817000b3565 |
start gradle check |
3ccfc04
to
7aec869
Compare
✅ Gradle Check success 7aec869316b11b9f53b343390bf8a1d9258e8507 |
Signed-off-by: Kunal Kotwani <[email protected]>
7aec869
to
fdbf247
Compare
Unrelated test failure:
|
start gradle check |
This seems to be affected by #2782 |
Will re run tests after #2795 gets merged in. |
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.
Thank you! It's a great opportunity for me to understand the rolling upgrade test from your new codes. 👍👍
switch (CLUSTER_TYPE) { | ||
case OLD: | ||
Version minNodeVersion = getMinNodeVersion(); | ||
if (minNodeVersion.before(Version.V_2_0_0)) { |
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.
When all the nodes in the cluster is in the same version, I think it's easier to directly use the variable UPGRADE_FROM_VERSION
. (Please see the other test classes in the directory https://github.com/opensearch-project/OpenSearch/blob/1.3.1/qa/rolling-upgrade/src/test/java/org/opensearch/upgrades/JodaCompatibilityIT.java#L77 and https://github.com/opensearch-project/OpenSearch/blob/1.3.1/qa/rolling-upgrade/src/test/java/org/opensearch/upgrades/MappingIT.java#L45)
In addition, I think getting the minNodeVersion
is originally designed to be used in a mixed-version cluster (case MIXED
), when an API response from nodes of different versions are different. My conclusion is derived from the original test case testAutoIdWithOpTypeCreate()
(https://github.com/opensearch-project/OpenSearch/blob/1.3.1/qa/rolling-upgrade/src/test/java/org/opensearch/upgrades/IndexingIT.java#L211-L213)
Further, learning from the above 2 tests classes, probably it will be more concise to use assumeTrue
to filter the versions to run the test. 😁
assumeTrue("Mapping types is removed in 2.0", UPGRADE_FROM_VERSION.beforeVersion.V_2_0_0));
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 was leaning on the minNodeVersion
check to avoid any race/weird condition before I actually push in the typed indices. It does not seem to be an issue in my tests. Moved it to a regular check.
assertTrue
will not work for all the cases since the bwcTest
runs checks between not just current branch but a bunch of versions depending on compatibility. (
for (Version bwcVersion : BuildParams.bwcVersions.wireCompatible) { |
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.
Ah, got your reason to use minNodeVersion
check 😄 👍. The current code looks good, but I need some time to understand the limitation of assumeTrue
you pointed out.
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.
The meaning of assumeTrue("...", UPGRADE_FROM_VERSION.beforeVersion.V_2_0_0);
is to filter the test to only run when upgrading from a cluster < 2.0 version.
I just learnt this from seeing the other test class, such as https://github.com/opensearch-project/OpenSearch/blob/1.3.1/qa/rolling-upgrade/src/test/java/org/opensearch/upgrades/JodaCompatibilityIT.java#L77
You could see the javadoc of assumeTrue()
(https://javadoc.io/doc/com.carrotsearch.randomizedtesting/randomizedtesting-runner/2.7.1/com/carrotsearch/randomizedtesting/RandomizedTest.html#assumeTrue-java.lang.String-boolean-)
condition - If false an AssumptionViolatedException is thrown by this method and the test case (should be) ignored. Tests that are assumption-failures do not break builds.
Breaking the assumption is the result we want. 😄
So in my opinion, using assumeTrue()
to filter the version to run the test can reduce your duplication usage of if (UPGRADE_FROM_VERSION.before(Version.V_2_0_0))
statement in every test case.
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 misread it as assertTrue
! This is a great find. Thanks for linking this 🙂
The if conditions currently do cover all of over scenarios, but will update with assumeTrue
whenever I push any changes out for the test.
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.
Sounds good! Yeah.. your PR does a good opportunity for me to find those interesting usages.
qa/rolling-upgrade/src/test/java/org/opensearch/upgrades/IndexingIT.java
Show resolved
Hide resolved
Signed-off-by: Kunal Kotwani <[email protected]>
|
||
switch (CLUSTER_TYPE) { | ||
case OLD: | ||
if (UPGRADE_FROM_VERSION.before(Version.V_2_0_0)) { |
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.
What's the behavior of this test when ran against main
running version 3.0
?
Will this only create domain but wouldn't perform any assertions. If this understanding is correct, it will be NoOp on main (and all next versions). In that case, shall we have ToDo for removal Or do not merge into main (better) ?
I understand this is coming from writing feature specific bwc tests which gets added/removed in specific version.
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.
Against 3.0, it will run against the previous wire compatible versions (v2.x.x). And yes, it will be a NoOp in the versions ahead.
Let me branch it off 2.0 instead.
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 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.
Looks like we also need this test in 2.x
branch? 😂
qa/rolling-upgrade/src/test/java/org/opensearch/upgrades/TypeRemovalIT.java
Show resolved
Hide resolved
"^\\[types removal\\] (.+) include_type_name (.+) is deprecated\\. The parameter will be removed in the next major version\\.$" | ||
); | ||
|
||
private void useIgnoreTypesRemovalWarningsHandler(Request request) { |
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'm curious is this new method having a same function with the existing method https://github.com/opensearch-project/OpenSearch/blob/1.3.1/test/framework/src/main/java/org/opensearch/test/rest/OpenSearchRestTestCase.java#L326 ?
Closing this in favor of #2901 |
Signed-off-by: Kunal Kotwani [email protected]
Description
Issues Resolved
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.