Skip to content

Conversation

liuyonghengheng
Copy link

…hen the convert_index_to_remote operation restored the target index .

Description

The "convert_index_to_remote" operation restored the target index suffixed whith "remote". In most cases, this new index will match the same policy as the original index, which can trigger the index management process again (although it will fail due to read-only ). This is not what we want. To avoid this issue, we can use the "remote" prefix instead of "_remote" suffix .

Related Issues

Resolves #1426

Check List

  • New functionality includes testing.
  • New functionality has been documented.
  • API changes companion pull request created.
  • Commits are signed per the DCO using --signoff.
  • Public documentation issue/PR created.

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.

…hen the convert_index_to_remote operation restored the target index .

Signed-off-by: liuyongheng <[email protected]>
.storageType(RestoreSnapshotRequest.StorageType.REMOTE_SNAPSHOT)
.renamePattern("^(.*)\$")
.renameReplacement("$1_remote")
.renameReplacement("remote_$1")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked at your issue. While I agree that restore action can lead to a policy starting off again but changing the index name may not be a full proof solution since there can be existing policies defined on pattern like remote_*

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably need a solution like this where during policy validation itself user defines a pattern to be appended to a restored index and probably during policy definition itself a exclude pattern template is set.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1.Even if we use this solution, I think we cannot fully avoid conflicts. We may still have local indexes with names matching pattern "abc* _demote*", so this template could affect local indexes like "abc*_demote*".
The solution of changing the remote suffix to the remote prefix is to solve the conflicts that always occur, and then we can enhanced and optimized the settings continue.

2.During define policy, set a exclude index pattern. I agree that this solution can resolve this issue fully, because the match index is the difference-set of index-pattern and exclude-index-pattern ,and it will not affect other indexes.

3.before "convert_index_to_remote" operation implemented and published, we implemented a solution internal named "searchable_snapshot", that use most origin settings of snapshots-restore,
so it's more flexible ,users can use rename_replacement setting to set the new index name, and can proactively avoid conflicts. If most thinks it's possible to add settings like "rename_deplacement" , I can also submit this implement code.

      {
        "name": "searchablesnapshot",
        "actions": [
          {
            "searchable_snapshot": {
              "repository": "my_s3_repository",
              "snapshot": "ss_{{ctx.index}}",
              "rename_pattern": "(.+)",
              "rename_replacement": "remote_$1",
              "index_settings": {
                "index.number_of_replicas": 0
              },
              "rename_alias_pattern":"(.+)",
              "rename_alias_replacement":"remote_$1"
            }
          }
        ],
        "transitions": [
          {
            "state_name": "delete"
          }
        ]
      }

4.Please provide as many ideas and advice as possible and have a discussions, I will implement the solution which most approve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants