Remove LegacyVersion.V_6.x Constants and Deprecated Code in OpenSearch 2.0

[adnapibar]

This is a clean up meta issue to track the removal of all LegacyVersion.V_6.x constants and code that are deprecated to be removed in OpenSearch 2.0.

• Remove 6.0.* version constants #1658
• Remove LegacyESVersion.V_6_1_x constants #1681
• Remove LegacyESVersion.V_6_2_x constants #1686
• Remove LegacyESVersion.V_6_3_x constants #1691
• Remove LegacyESVersion.V_6_4_x constants #1787
• Remove LegacyESVersion.V_6_5_x constants #1794
• Remove LegacyESVersion.V_6_6_x constants #1804
• Remove LegacyESVersion.V_6_7_x constants #1807
• Remove LegacyESVersion.V_6_8_x constants #1869
• [Remove] Deprecated Zen1 Discovery #1216
• Remove Deprecated SimpleFS #1639
• Remove copy_settings parameter from split and shrink API
• [Remove] Deprecated Synced Flush API #1761
• Remove boost parameter on field mappings
• Remove deprecated search.remote settings #1870
• Remove deprecated transport client #1781
• Enforce soft deletes #1903
• [Remove] Segment memory estimation and tracking #2029
• [Remove] Default Mapping #2151

[saratvemulapalli]

Just saw this issue, can we also take care of TransportClient ?
Here is an issue I opened up yesterday: #1669

[adnapibar]

Just saw this issue, can we also take care of TransportClient ? Here is an issue I opened up yesterday: #1669

Thanks @saratvemulapalli !

[lukas-vlcek]

I think there are still some leftovers, at least in org.opensearch.gradle.testclusters package.

For example OpenSearchCluster or OpenSearchNode classes still contain several conditions that use string constants like "6.2.0", "6.3.0", "6.5.0" ... etc. (They do not make use of Version or LegacyESVersion instance, maybe that is why these cases were not handled yet?)

[adnapibar]

I think there are still some leftovers, at least in org.opensearch.gradle.testclusters package.

For example OpenSearchCluster or OpenSearchNode classes still contain several conditions that use string constants like "6.2.0", "6.3.0", "6.5.0" ... etc. (They do not make use of Version or LegacyESVersion instance, maybe that is why these cases were not handled yet?)

Thanks @lukas-vlcek - we will be removing those as well. Feel free to raise a PR if you'd like to contribute :)

[davidlago]

We depend on the TransportClient in the security plugin. The effort to remove is significant (i.e. in the tens of hours of work). Without these changes, this is a build-breaking issue (we will not have working 2.0 builds until this is addressed). Would it be OK if we postpone this removal until the next major version? I'm weighing in the risks of breaking the build and delaying the release vs. removing something that has been deprecated since 7.0

[CEHENKLE]

@nknize I hate dragging this to 3.0, but I don't see an immediate harm to keeping it around but deprecated. What do you think?

[dblock]

@davidlago Do you have an open child issue from here yet?

opensearch-project/security#1578

[dblock]

@nknize I hate dragging this to 3.0, but I don't see an immediate harm to keeping it around but deprecated. What do you think?

Note that most plugins currently are building 1.3.0 in main, so there's no 2.0 build with plugins for a while anyway. I think we should do the work in the security plugin before removing as part of 2.0, and not punt this.

[nknize]

most plugins currently are building 1.3.0 in main

This is the bigger concern. The main branch has quickly diverged from 1.x so plugins really need to have a branch that can build from 2.0.0 core; even if it's just a feature branch. Unfortunately we're going to run into more than just TransportClient conflicts (e.g., security also still supports soft-delete parameter which is now removed in main) and as that list grows so will the amount of delay to having a functional 2.0 bundle ready for public preview.

[saratvemulapalli]

most plugins currently are building 1.3.0 in main

This is the bigger concern. The main branch has quickly diverged from 1.x so plugins really need to have a branch that can build from 2.0.0 core; even if it's just a feature branch. Unfortunately we're going to run into more than just TransportClient conflicts (e.g., security also still supports soft-delete parameter which is now removed in main) and as that list grows so will the amount of delay to having a functional 2.0 bundle ready for public preview.

+1 when we started setting up the branches 2.0.0 was far down the line.
I am worried plugins will see lot more problems than we can guess (eg: Gradle 7, TransportClient etc).
We should start replicating the same branching strategy as OpenSearch for rest of the bundle.

[kavilla]

So just be clear we no longer support migrating from 6.8 to OpenSearch latest? https://opensearch.org/docs/latest/upgrade-to/upgrade-to/#upgrade-paths. I don't see an issue in the docs repo about not supporting this.

[anasalkouz]

Moving remaining effort to 3.0. #2773. Closing this for now