elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.78k stars 8.18k forks source link

Update Snapshot Restore s3 repository settings to support secure client settings #70492

Open cjcenizal opened 4 years ago

cjcenizal commented 4 years ago

Background

Per the s3 repository docs:

In addition to the above settings, you may also specify all non-secure client settings in the repository settings. In this case, the client settings found in the repository settings will be merged with those of the named client used by the repository. Conflicts between client and repository settings are resolved by the repository settings taking precedence over client settings.

The "non-secure client settings" mentioned can be found in the s3 repository client docs:

Per the notes at the bottom of the above link:

There are a number of storage systems that provide an S3-compatible API, and the repository-s3 plugin allows you to use these systems in place of AWS S3. To do so, you should set the s3.client.CLIENT_NAME.endpoint setting to the system’s endpoint.

Minio is an example of a storage system that provides an S3-compatible API. The repository-s3 plugin allows Elasticsearch to work with Minio-backed repositories as well as repositories stored on AWS S3.

The problem

The UI for editing an S3 repository is currently missing support for non-secure client settings:

image

Likewise, our schema validation doesn't accept these settings when you try to create and update an s3 repository. This means that the UI doesn't support the use-case mentioned by the docs, in which users can create a Minio-compatible repository by configuring an S3 repository with a custom endpoint.

What's broken

Concretely, this manifests in a broken UX when a Cloud or ECE user edits the found-snapshots default repository to point to Minio and then tries to make changes to it in Snapshot Restore.

The solution

We need to update both the UI and API to support non-secure client settings for S3 repositories. I suggest borrowing content from the docs and surfacing it as help text in the UI to inform users about the purpose behind these settings, and to describe how they merge with and override client settings if they're defined on the repository. Each field will also need ample help text to explain what its role.

Because this also seems like an advanced use case, I think it makes sense to hide these fields inside of an accordion or behind a toggle, similar to how we hide the advanced settings for follower indices.

image

image

elasticmachine commented 4 years ago

Pinging @elastic/es-ui (Team:Elasticsearch UI)

elasticmachine commented 3 weeks ago

Pinging @elastic/kibana-management (Team:Kibana Management)