[Manual] Revert Add bwcVersion 2.5.0 (#5003)

[peternied]

Description

In the middle of getting ready for the 2.4.0 release our backward compatibility tests for security started failing, which looks to be related to this change.

• Add bwcVersion 2.5.0 #5003

Reverting this commit to unblock pull request checks in to main.

How we can stage changes like this before the 2.5.0 build is ready, or do we need to careful make these changes when main branches won't be impacted?

Signed-off-by: Peter Nied [email protected]

Issues Resolved

• Related BWC Tests are failing on mixedClusterTask #5076
• Resolves BWC Tests are failing on main security#2221

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)

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.

[peternied]

@kotwanikunal @VachaShah would you be able to take a look?

[andrross]

My understanding is that this version has to match the version that is built by the OpenSearch/2.x branch, or else the backward compatibility tests in OpenSearch will fail. @VachaShah Can you weigh in here?

[kotwanikunal]

My understanding is that this version has to match the version that is built by the OpenSearch/2.x branch, or else the backward compatibility tests in OpenSearch will fail. @VachaShah Can you weigh in here?

+1 on this. It has to stay consistent AFAIK.

[dblock]

This doesn't feel right. @peternied says that security repo is running 2.4.0 -> 3.0.0 BWC tests, when 3.0.0 was updated to 2.5.0 security repro broke with: java.lang.IllegalStateException: Received message from unsupported version: [2.4.0] minimal compatible version is: [2.5.0]. I think this is expected, the idea is that only latest 2.x will be upgradable to 3.0 when that ships, and this is what we're seeing now since 2.5 is a new thing that will exist.

@nknize Is this something we still want? Should we relax it?

It sounds like a sequencing problem and we just need a 2.5 distribution build, which is coming via automation in the 24 hours since 2.x was incremented to 2.5.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/6403/
• CommitID: b4b0a95
  Please examine the workflow log, locate, and copy-paste the failure below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[peternied]

Happy to abandon this change if there are other fixes to unblock the security.

[peternied]

Execution failed for task ':distribution:bwc:minor:buildBwcLinuxTar'.
> Building 2.4.0 didn't generate expected file /var/jenkins/workspace/gradle-check/search/distribution/bwc/minor/build/bwc/checkout-2.x/distribution/archives/linux-tar/build/distributions/opensearch-min-2.4.0-SNAPSHOT-linux-x64.tar.gz

Looks like other dependent changes are already in, I'm guessing a revert is no longer possible without involving many branches.

[peternied]

I'm closing out this pull request since it will not be merged, it looks like the root cause has been found and is being worked on. Moving forward seems like like the correct path.

• [Bug]: Version workflow to auto update input manifests is failing opensearch-build#2854

[peternied]

FYI I've captured @dblock question into a new OpenSearch issue for further consideration

• [Bug] Version increments breaks downstream plugins #5091