[BUG] when index rollover occurs, alias filter is not copied and deleted

[oridool]

What is the bug?
Create an index rollover policy and associate to index (with index template).
When creating the first index, the index contains an alias for rollover. This alias also contains a filter.
After rollover, additional index is created as expected, but the the filter is missing in the alias of the new index.
Moreover, the alias filter in the original index (before rollover) is also deleted.

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

1. Create ISM policy

PUT _plugins/_ism/policies/rollovertests_policy
{
  "policy": {
    "description": "test rollover policy.",
    "default_state": "rollover",
    "states": [
      {
        "name": "rollover",
        "actions": [
          {
            "rollover": {
              "min_index_age": "2m"
            }
          }
        ],
        "transitions": []
      }
    ] 
    ,
    "ism_template": {
      "index_patterns": ["rollovertests*"],
      "priority": 100
    }
  }
}

3. Create index template with relation to policy and rollover_alias.

PUT  _index_template/rollovertests_template
{
  "index_patterns": [
    "rollovertests-*"
  ],
  "template": {
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 1,
      "plugins.index_state_management.rollover_alias": "rollovertests"
    },
    "mappings": {
      "_routing": {
      "required": true
      },
      "properties": {
        "timestamp": {
          "type": "date",
          "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
        }
      }
    }
  }
}

5. Create a new index with alias and filter

PUT rollovertests-000001
{
  "aliases": {
    "rollovertests": {
      "is_write_index": true,
      "filter": {
        "term": {
          "timestamp": "1574641891142"
        }
      }
    }
  }
}

7. Make sure index was created properly with the alias

GET rollovertests-*/_alias

{
  "rollovertests-000001" : {
    "aliases" : {
      "rollovertests" : {
        "filter" : {
          "term" : {
            "timestamp" : "1574641891142"
          }
        },
        "is_write_index" : true
      }
    }
  }
}

7. Wait few minutes for rollover action.
8. Query the newly generated index and the original index. You can see that filter is missing in both.

GET rollovertests-*/_alias


{
  "rollovertests-000002" : {
    "aliases" : {
      "rollovertests" : {
        "is_write_index" : true
      }
    }
  },
  "rollovertests-000001" : {
    "aliases" : {
      "rollovertests" : {
        "is_write_index" : false
      }
    }
  }
}

What is the expected behavior?
Alias filter should be copied to new index after rollover.
Alias filter should not be deleted from original alias and index.

What is your host/environment?

• OS: AWS OpenSearch
• Version : 1.3.2
• Plugins

[stevanbz]

Hi.
Tnx for describing the bug in step by step manner with clear explanation so it's easy to reproduce.

I did short investigation re the problem you described. The same thing is happening once you try to do a rollover directly against the cluster (without creation of the policy with rollover step) ie.

1. Create an index with alias:
   PUT rollovertests-000001 { "aliases": { "rollovertests": { "is_write_index": true, "filter": { "term": { "timestamp": "1574641891142" } } } } }
2. GET rollovertests-*/_alias to confirm that index with alias is created
3. Do a manual rollover against the cluster directly ie.
   POST rollovertests/_rollover
   and check the rollover results by executing GET rollovertests-*/_alias
   Response example:
   { "rollovertests-000001" : { "aliases" : { "rollovertests" : { "is_write_index" : false } } }, "rollovertests-000002" : { "aliases" : { "rollovertests" : { "is_write_index" : true } } } }

So I would say it's rather behavior of the OpenSearch itself then a behavior of index-management plugin.
Right now, I am trying to understand how rollover action is performed, and hopefully I will come with some more details about it.

[JoeChizmasTCG]

Adding context that as of May of 2023 - there is still a known issue in OpenSearch, based upon the original post above. In Code Block 3 above, when the template is being created, the code is setting the rollover alias with this command:
"plugins.index_state_management.rollover_alias": "rollovertests"

Whilst this will return an acknowledged/true, and whilst it will roll over the first time, this rollover alias will NOT carry forward to the first rolled over index. If, however, you replace the 'plugins.' prefix with 'opendistro.', then the rollover alias will copy forward in subsequent indices that are created.

So replacing it with this line, and your rollover alias will carry forward:
"opendistro.index_state_management.rollover_alias": "rollovertests"

This suggest that 'plugins.' is deprecated, so it should return either a false or at least a deprecation warning that the path is 'opendistro.' versus 'plugins.' As it is, it not only accepts the command, but if present, the rollover function will still acknowledge it. It is just a setting that is no longer carried into the new index, so only a single rollover will succeed.

[petardz]

Adding context that as of May of 2023 - there is still a known issue in OpenSearch, based upon the original post above. In Code Block 3 above, when the template is being created, the code is setting the rollover alias with this command: "plugins.index_state_management.rollover_alias": "rollovertests"

Whilst this will return an acknowledged/true, and whilst it will roll over the first time, this rollover alias will NOT carry forward to the first rolled over index. If, however, you replace the 'plugins.' prefix with 'opendistro.', then the rollover alias will copy forward in subsequent indices that are created.

So replacing it with this line, and your rollover alias will carry forward: "opendistro.index_state_management.rollover_alias": "rollovertests"

This suggest that 'plugins.' is deprecated, so it should return either a false or at least a deprecation warning that the path is 'opendistro.' versus 'plugins.' As it is, it not only accepts the command, but if present, the rollover function will still acknowledge it. It is just a setting that is no longer carried into the new index, so only a single rollover will succeed.

On what version are you reproducing this? I tried managed 2.5 and opensource 3.0(main branch) and couldn't reproduce it.

Regarding index templates, creating index_template will not do anything to any existing index. It will affect only indices matching patterns, created after this index_template.