[Remote Translog] Trimming based on Remote Segment Store

[gbbafna]

Description

When remote segment is enabled, the min generation translog retain should just use the seq no upload there instead of using local checkpoint of safe commit , which gets updated only on flush .

Also added Integ tests of failover for Remote Translog .

Related Issues

#7381
#6195
#5670

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.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

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

[github-actions]

Gradle Check (Jenkins) Run Completed with:

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

[github-actions]

Gradle Check (Jenkins) Run Completed with:

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

[github-actions]

Gradle Check (Jenkins) Run Completed with:

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

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/15381/
• CommitID: bb497de

[ashking94]

can we add an IT that checks if the trimming is happening as expected? Validate the number of translog files (tlog/ckp) in the repo? I had done something similar here - https:/opensearch-project/OpenSearch/blob/main/server/src/internalClusterTest/java/org/opensearch/remotestore/RemoteStoreRefreshListenerIT.java#L85

[gbbafna]

can we add an IT that checks if the trimming is happening as expected? Validate the number of translog files (tlog/ckp) in the repo? I had done something similar here - https:/opensearch-project/OpenSearch/blob/main/server/src/internalClusterTest/java/org/opensearch/remotestore/RemoteStoreRefreshListenerIT.java#L85

I have UTs covering the trimming part comprehensively . IT is testing the failover doesn't cause any data loss .

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/15469/
• CommitID: d396d72

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❕
• TEST FAILURES:

      1 org.opensearch.remotestore.SegmentReplicationRemoteStoreIT.testScrollWithOngoingSegmentReplication

• URL: https://build.ci.opensearch.org/job/gradle-check/15473/
• CommitID: bad54d9
  Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❕
• TEST FAILURES:

      2 org.opensearch.remotestore.RemoteStoreRefreshListenerIT.testRemoteRefreshRetryOnFailure

• URL: https://build.ci.opensearch.org/job/gradle-check/15474/
• CommitID: 47775df
  Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[Bukhtawar]

Did it even run codecov tests this time?

[gbbafna]

Did it even run codecov tests this time?

Yes it did : https://app.codecov.io/gh/opensearch-project/OpenSearch/pull/7383

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-7383-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 613f4aa046912b583925a9a03cb2294efd2a002c
# Push it to GitHub
git push --set-upstream origin backport/backport-7383-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-7383-to-2.x.

[monusingh-1]

hi @gbbafna, there is backport2.x label present, will this be backported to 2.x?

[gbbafna]

@monu-aws : Yes, I will be backporting it by 24/05.