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
}
}
}
- origin index: log_0001
- 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.