hot_to_warm
{
"policy": {
"policy_id": "hot_to_warm",
"description": "Demonstrate a hot-warm workflow.",
"default_state": "hot",
"states": [
{
"name": "hot",
"actions": [],
"transitions": [
{
"state_name": "warm",
"conditions": {
"min_index_age": "1d"
}
}
]
},
{
"name": "warm",
"actions": [
{
"timeout": "24h",
"retry": {
"count": 5,
"backoff": "exponential",
"delay": "1h"
},
"warm_migration": {}
}
],
"transitions": []
}
]
}
}
The above policy has two states named as hot and warm. The default state is hot. As per the policy, you can see that hot state is transitioning to warm state when the condition is met. The condition is set as index age of 1 day. After 1 day of index creation, it will move to warm state where the action of warm_migration is mentioned. Once the index is in warm there are no transitions defined.
After you attach a policy to an index, ISM creates a job that runs every 30 to 48 minutes to perform policy actions, check conditions, and transition the index into different states. Once a policy is applied, the job status may take 30 - 48 minutes to change it’s status. After that timeframe you should see the job status as ‘Running’. You will have to keep the domain up and running for the next 24 hours to see the ISM in action.
The policy will be executed on the index only after 24 hrs of index creation time. For the migration to happen, the domain need to up and running for that much time.
Managed Indices
and verifying the State
,Action
and Info
fields.Congragulations! You have automated the ultrawarm migration of your index using index state management.