[FEATURE] Index State Management Shrink Action

[downsrob]

What solution would you like?
We will need to add documentation for a new action in the Index State Management policies page.
The shrink action is a new type of action in the ISM that can be used to reduce the number of primary shards for a user specified index.
Open issue in ISM backend repo opensearch-project/index-management#40
Pull request for backend change opensearch-project/index-management#326 This PR has a lot of additional information on shrink action parameters, steps, and implementation.
Pull request for frontend change opensearch-project/index-management-dashboards-plugin#176

Use cases

In the current state of ISM, the only way to reduce the associated shard total for an index is to reduce the number of replicas per shard. However, this does not solve the inherent problem of having too many primary shards in the first place.

The shrink action will enable the following use cases.

1. Users will be able to specify the number of primary shards that the target index should contain.
2. Users will be able to specify a max shard size for the primary shards in the target index.
3. Users will be able to specify a percentage that they want to shrink the index to.

Input Schema

The new action will have the following configurable parameters in it's definition:

"shrink": {
    "num_new_shards": {
        "type": "integer"
    },
    "max_shard_size": {
        "type": "keyword"
    },
    "percentage_of_source_shards": {
        "type": "double"
    },
    "target_index_name_template": {
        "type": "object"
    },
    "aliases": {
        "type": "object"
    },
    "force_unsafe": {
        "type": "boolean"
    }
}

Only one of num_new_shards, max_shard_size, or percentage_of_source_shards may be set.
Target_index_name_template, aliases, and force_unsafe are optional.

Do you have any additional context?
Screenshots are included in UI PR

[downsrob]

Looks like I don't have permissions to tag this as 2.0. This feature is targeted for 2.0 preview and will add additional API and UI options to the existing policy creation system.

Could this issue be tagged with 2.0, API, and UI?

[Naarcha-AWS]

@downsrob: Is the UI for this action testable yet?

[downsrob]

Not yet, I am working on that now and expecting to get it into a PR mid next week

[Naarcha-AWS]

@downsrob: Feel free to review: #496.

[dblock]

Is this still 2.0 @Naarcha-AWS ?

[Naarcha-AWS]

Yes @dblock

[downsrob]

Thank you @Naarcha-AWS for your help. I have updated the issue with the UI PR and some new changes regarding changing the target_index_suffix to target_index_name_template. Also, I believe that the aliases field is a bit difficult so I will add some more context here:
Aliases field is object type, but must be an array of alias objects. The alias objects are most similar to this https://opensearch.org/docs/1.2/opensearch/rest-api/alias/#request-body and the parameter descriptions and types are exactly the same. The layout of the fields is a little different, however, so I will just specify it all here. The key of the object is the name of the alias.
Alias object:

{
  <alias-name, required string>: {
    "filter": <optional object, this is a [query dsl string](https://opensearch.org/docs/latest/opensearch/query-dsl/index/)>,
    "index_routing": <optional string, same as linked [here](https://opensearch.org/docs/1.2/opensearch/rest-api/alias/#request-body)>,
    "search_routing": <optional string, same as linked [here](https://opensearch.org/docs/1.2/opensearch/rest-api/alias/#request-body)>,
    "routing": <optional string, same as linked [here](https://opensearch.org/docs/1.2/opensearch/rest-api/alias/#request-body)>,
    "is_write_index": <optional boolean, same as linked [here](https://opensearch.org/docs/1.2/opensearch/rest-api/alias/#request-body) default is false>,
    "is_hidden": <optional boolean, same as linked [here](https://opensearch.org/docs/1.2/opensearch/rest-api/alias/#request-body) default is false>
  }
}

The simplest example to just add the alias 'my-alias' without any custom configuration would be:

"aliases": [
  {
    "my-alias": {}
  }
]

This would add the "my-alias" alias to the output shrink index, additional aliases can be added in the array, for example:

"aliases": [
  {
    "my-alias": {}
  },
  {
    "my-second-alias": {
      "is_write_index": false,
      "filter": {
        "multi_match": {
          "query": "QUEEN",
          "fields": ["speaker", "text_entry"]
        }
      },
      "index_routing" : "1",
      "search_routing" : "1"
    }
  },
]