[BUG] 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

[liuyonghengheng]

What is the bug?
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 .

How can one reproduce the bug?
Steps to reproduce the behavior:
1.

{
  "policy": {
    "description": "remote",
    "default_state": "hot",
    "schema_version": 1,
    "states": [
      {
        "name": "hot",
        "actions": [
          {
            "rollover": {
              "min_index_age": "7d",
              "min_primary_shard_size": "30gb"
            }
          }
        ],
        "transitions": [
          {
            "state_name": "warm"
          }
        ]
      },
      {
        "name": "warm",
        "actions": [
          {
            "replica_count": {
              "number_of_replicas": 1
            }
          },
          {
            "allocation": {
              "require": {
                "temp": "warm"
              }
            }
          }
        ],
        "transitions": [
          {
            "state_name": "remote"
          }
        ]
      },
      {
        "name": "remote",
        "actions": [
          {
            "snapshot": {
                "repository": "my_backup",
                "snapshot": ""
            }, 
            "convert_index_to_remote": {
                "repository": "my_backup",
                "snapshot": ""
            }
          }
        ]
      }
    ],
    "ism_template": {
      "index_patterns": ["log*"],
      "priority": 100
    }
  }
}

2. origin index: log_0001
3. remote index: log_0001_remote which will trigger this policy too!

What is the expected behavior?
if we use the name “remote_log_0001” which will not trigger the same policy as the original index

What is your host/environment?

• OS: ubuntu22
• Version 3.0.0

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
Add any other context about the problem.

[wntmddus]

You can prevent this by adding higher priority index template on remote
PUT _template/remote_exclude_template { "index_patterns": ["*_remote*"], "priority": 200, "settings": { "opendistro.index_state_management.policy_id": null } }

But this can also be a solution to be used.

[liuyonghengheng]

You can prevent this by adding higher priority index template on remote PUT _template/remote_exclude_template { "index_patterns": ["*_remote*"], "priority": 200, "settings": { "opendistro.index_state_management.policy_id": null } }

But this can also be a solution to be used.

Thx, I aggre with you, but when users first use this action, they are not aware that this solution is needed to avoid the problem, and this undoubtedly increases the using cost for users. So, I suggest using "remote_"prefixes to completely solve this problem.

[liuyonghengheng]

Hi @bowenlan-amzn ,can you please help take a look at this issue? This issue has been submitted for over 2 weeks now

[andrross]

@liuyonghengheng Feel free to submit a PR if you'd like to contribute this feature

[ccben87]

Hi @andrross, @liuyonghengheng has created a PR at #1427

@andrross or @bowenlan-amzn Is this project planning, generally speaking, to adopt the approach of moving from a "remote" suffix to a "remote" prefix? The reason I ask is I'm wanting to pull this into my personal backport of the feature into 2.x and want to start a new cluster ASAP and don't want to have to adopt the rename change at a later date. I can always adjust if there's minor code edits etc. but I'm just seeking to understand the overall direction to address this bug report.

[liuyonghengheng]

@liuyonghengheng Feel free to submit a PR if you'd like to contribute this feature

Thx, I have submitted a PR, If possible, could you please help review it （ https://github.com/opensearch-project/index-management/pull/1427）

[andrross]

@liuyonghengheng Apologies, I missed that you had already linked a PR.

@ankitkala Can we get someone with expertise on this plugin to follow up here?

[vikasvb90]

@liuyonghengheng Added a comment on your PR. Let me know if it makes sense.

[liuyonghengheng]

@liuyonghengheng Added a comment on your PR. Let me know if it makes sense.

@vikasvb90 Thx，May be we should discuss the solution again，I listed 3 optional known solution in this PR，and gave some personal view，please review it

[rpasche]

You can prevent this by adding higher priority index template on remote PUT _template/remote_exclude_template { "index_patterns": ["*_remote*"], "priority": 200, "settings": { "opendistro.index_state_management.policy_id": null } }

But this can also be a solution to be used.

@wntmddus I tried this, but it does not work. I assume because the existing index is converted (and is not a newly created index, where the index_template also counts in).

{
  "index_templates": [
    {
      "name": "all_remote",
      "index_template": {
        "index_patterns": [
          "*_remote"
        ],
        "template": {
          "settings": {
            "index": {
              "plugins": {
                "index_state_management": {
                  "policy_id": null
                }
              }
            }
          }
        },
        "composed_of": [],
        "priority": 200,
        "_meta": {
          "flow": "simple"
        }
      }
    }
  ]
}

Another issue. Trying to remove the policy from those converted indices results in another error:

POST _plugins/_ism/remove/*_remote...

{
  "error": {
    "root_cause": [
      {
        "type": "index_management_exception",
        "reason": "Failed to remove policy because ISM auto_manage setting update requests failed with exception:"
      }
    ],
    "type": "index_management_exception",
    "reason": "Failed to remove policy because ISM auto_manage setting update requests failed with exception:",
    "caused_by": {
      "type": "exception",
      "reason": "java.lang.Exception: Failed to remove policy because ISM auto_manage setting update requests failed with exception:"
    }
  },
  "status": 500
}