[BUG] 2.11.1 restoring kibana indices from snapshots through UI fails

[sandervandegeijn]

Describe the bug

I'm trying to do a disaster recovery of my cluster. I have a snapshot containing the following indices:

Restoring all indexes without rename to a fresh cluster:

The alias option does not make a difference. I'm restoring all indices, option for specific indices is active to show which indices I'm restoring.

{"message":"alias [.kibana] has more than one index associated with it [.kibana_1, restored_.kibana_3], can't execute a single index op: illegal_argument_exception: [illegal_argument_exception] Reason: alias [.kibana] has more than one index associated with it [.kibana_1, restored_.kibana_3], can't execute a single index op","statusCode":400,"error":"Bad Request"}

Related component

Storage:Snapshots

To Reproduce

See above

Expected behavior

Restore is executed or if this is not the way to do this, the user is blocked and instructions are provided. You want a clear path when you are under stress because of a failed production environment.

Additional Details

Default 2.11.1 images with S3 plugin added.

[sandervandegeijn]

Doing the restore with the admin certificate works as expected.

[kavilla]

@opensearch-project/admin please re-route this to https://github.com/opensearch-project/index-management-dashboards-plugin.

This might require @opensearch-project/opensearch-ux to provide insight. It seems like the issue could be appear that this UI cat/indices even if the current user snapshotting does not have write permissions to those indices. So maybe some indicator of that or filtering indices that they can make indices.

[sandervandegeijn]

I'm doing it from the ui with the admin rol, all_access. But that isn't enough, you need key based admin auth.

The experience has always been somewhat difficult and frustrating, so I have created a new issue to polish the flow (describing it from a utopian point of view ;) )

opensearch-project/OpenSearch#11894

[dblock]

Catch All Triage - 1 2 3 4 5