Is your feature request related to a problem?
In Reader/Writer Separation architecture, when indices migrate through ISM lifecycle states (e.g., Hot → Warm → Cold), writer shards (primary + write replicas) continue to consume resources even when no longer receiving write traffic.
For example, in a typical log management use case, Hot tier indices receive active writes for 7 days, then transition to Warm tier where writes become minimal or stop entirely. There's currently no automated way to optimize these resources while keeping indices searchable.
What solution would you like?
A new ISM action (e.g., optimize_for_search) that automatically scales down writer shards during state transitions.
What alternatives have you considered?
- Manual API calls: Users could manually call the
_scale API for each index, but this doesn't scale well for clusters managing thousands of indices with ISM policies
- External automation: Building custom scripts/tools outside ISM, but this adds complexity and doesn't integrate with existing lifecycle management workflows
Do you have any additional context?
Is your feature request related to a problem?
In Reader/Writer Separation architecture, when indices migrate through ISM lifecycle states (e.g., Hot → Warm → Cold), writer shards (primary + write replicas) continue to consume resources even when no longer receiving write traffic.
For example, in a typical log management use case, Hot tier indices receive active writes for 7 days, then transition to Warm tier where writes become minimal or stop entirely. There's currently no automated way to optimize these resources while keeping indices searchable.
What solution would you like?
A new ISM action (e.g.,
optimize_for_search) that automatically scales down writer shards during state transitions._scaleAPI (Search only replicas (scale to zero) with Reader/Writer Separation OpenSearch#17299) to setsearch_only: trueWhat alternatives have you considered?
_scaleAPI for each index, but this doesn't scale well for clusters managing thousands of indices with ISM policiesDo you have any additional context?