Updating filters as well during Alias update

[gbbafna]

Description

Alias filter changes aren't getting replicated to follower cluster.

On inspecting code, the logic to replicate alias is missing code to replicate filter. This results in inconsistent alias on the follower end whenever an alias filter is updated.

This change adds the logic to copy the filters as well . I have also verified that there is no other alias metadata we are missing.

Issues Resolved

#490

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

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.

[ankitkala]

LGTM

[codecov-commenter]

Codecov Report

Merging #491 (4d4ef8a) into main (a859596) will decrease coverage by 0.57%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##               main     #491      +/-   ##
============================================
- Coverage     75.16%   74.59%   -0.58%     
+ Complexity     1007     1005       -2     
============================================
  Files           141      141              
  Lines          4579     4582       +3     
  Branches        506      507       +1     
============================================
- Hits           3442     3418      -24     
- Misses          823      844      +21     
- Partials        314      320       +6     

Impacted Files	Coverage Δ
...rch/replication/task/index/IndexReplicationTask.kt	71.26% <100.00%> (+0.19%)	⬆️
...rch/replication/action/status/ShardInfoResponse.kt	72.26% <0.00%> (-19.33%)	⬇️
...earch/replication/metadata/UpdateIndexBlockTask.kt	74.19% <0.00%> (-6.46%)	⬇️
...action/stop/TransportStopIndexReplicationAction.kt	69.33% <0.00%> (-5.34%)	⬇️
...arch/replication/task/autofollow/AutoFollowTask.kt	74.32% <0.00%> (+1.35%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[krishna-ggk]

Can we also check if any other attributes need to be copied?

For example in addition to indexRouting & searchRouting, there is routing attribute.

[gbbafna]

Yes, I have checked for all the attributes . routing attribute gets converted into indexRouting & searchRouting

[saikaranam-amazon]

we should consider having validation checks after overall metadata update, obtain diff and publish the index stats.

• Can we employ similar mechanism as restore for updating overall index metadata?

[gbbafna]

Yes, we can enhance the status api to reflect the same .

Can we employ similar mechanism as restore for updating overall index metadata?

the current metadata sync is a condensed version for same. What is main delta in the mechanism you are referring to ? can we track these as part of other issue and take that forward ?

[krishna-ggk]

we should consider having validation checks after overall metadata update, obtain diff and publish the index stats.

Are you referring to comparing with leader again? If so, it may be end up with false positives as updates to metadata/alias on leader could be moving target. If not, then agree - it can be a simpler validation by comparing "expected" update which we can capture while building request object.

[saikaranam-amazon]

Are you referring to comparing with leader again? If so, it may be end up with false positives as updates to metadata/alias on leader could be moving target

No, i was referring to the response already obtained as part of the this update from the leader. This will ensure that the metadata diff we obtained from the leader(minus replication specific settings etc) is on par with the current updated index state on the follower.

What is main delta in the mechanism you are referring to ? can we track these as part of other issue and take that forward ?

I was referring to the diff on overall IndexMetadata itself but in the current form, the response obtained from the leader (minus repl metadata for the index which we want to override) and the response after the update from the follower index.

Ideally, these two should be equal and any deviation from this should be counted towards replication_metadata_failure as part of the index stats.

[saikaranam-amazon]

Opened issue to track the overall changes - #498

[krishna-ggk]

Overall fix looks good to me and we can track validation of applied metadata separately. Only contingent action is on getting successful CI run post which we can merge this.

[opensearch-trigger-bot]

The backport to 1.1 failed:

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

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-1.1 1.1
# Navigate to the new working tree
cd .worktrees/backport-1.1
# Create a new branch
git switch --create backport/backport-491-to-1.1
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 4470a774e4a49d72423c07af87a7754eeeb5116a
# Push it to GitHub
git push --set-upstream origin backport/backport-491-to-1.1
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-1.1

Then, create a pull request where the base branch is 1.1 and the compare/head branch is backport/backport-491-to-1.1.

[opensearch-trigger-bot]

The backport to 1.2 failed:

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

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-1.2 1.2
# Navigate to the new working tree
cd .worktrees/backport-1.2
# Create a new branch
git switch --create backport/backport-491-to-1.2
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 4470a774e4a49d72423c07af87a7754eeeb5116a
# Push it to GitHub
git push --set-upstream origin backport/backport-491-to-1.2
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-1.2

Then, create a pull request where the base branch is 1.2 and the compare/head branch is backport/backport-491-to-1.2.