Small changes to S3 repo docs #3350
Conversation
- Mention EC2 instance roles as well as ECS roles and K8s service accounts. - Mention reliability of S3-compatible storage as well as consistency & performance.
🔍 Preview links for changed docs |
| By default {{es}} communicates with your storage system using HTTPS, and validates the repository’s certificate chain using the JVM-wide truststore. Ensure that the JVM-wide truststore includes an entry for your repository. If you wish to use unsecured HTTP communication instead of HTTPS, set `s3.client.CLIENT_NAME.protocol` to `http`. | ||
|
|
||
| There are many systems, including some from very well-known storage vendors, which claim to offer an S3-compatible API despite failing to emulate S3’s behavior in full. If you are using such a system for your snapshots, consider using a [shared filesystem repository](shared-file-system-repository.md) based on a standardized protocol such as NFS to access your storage system instead. The `s3` repository type requires full compatibility with S3. In particular it must support the same set of API endpoints, with the same parameters, return the same errors in case of failures, and offer consistency and performance at least as good as S3 even when accessed concurrently by multiple nodes. You will need to work with the supplier of your storage system to address any incompatibilities you encounter. Don't report {{es}} issues involving storage systems which claim to be S3-compatible unless you can demonstrate that the same issue exists when using a genuine AWS S3 repository. | ||
| There are many systems, including some from very well-known storage vendors, which claim to offer an S3-compatible API despite failing to emulate S3’s behavior in full. If you are using such a system for your snapshots, consider using a [shared filesystem repository](shared-file-system-repository.md) based on a standardized protocol such as NFS to access your storage system instead. The `s3` repository type requires full compatibility with S3. In particular it must support the same set of API endpoints, with the same parameters, return the same errors in case of failures, and offer consistency, performance, and reliability at least as good as S3 even when accessed concurrently by multiple nodes. You will need to work with the supplier of your storage system to address any incompatibilities you encounter. Don't report {{es}} issues involving storage systems which claim to be S3-compatible unless you can demonstrate that the same issue exists when using a genuine AWS S3 repository. |
There was a problem hiding this comment.
@DaveCTurner shouldn't this be checked by the verify repo API call?
Said differently, can a customer be 100% certain that their system will be ok as long as the API call gives the green light.
There was a problem hiding this comment.
No, as per the docs you linked the verify repo API call is just there to ...
Check for common misconfigurations in a snapshot repository
No certainty here.
There was a problem hiding this comment.
I feel we need to be more prescriptive here. Either have an API call that can give full clearance as to repo capabilities, or specifically call out support for specific S3 providers (and as a result, be explicit about non-support of others).
Thoughts?
There was a problem hiding this comment.
have an API call that can give full clearance as to repo capabilities
We do what we can in terms of testing compatibility by experiment but such tests cannot be a positive indicator of compatibility, they can only report failures. We call out (e.g. in these docs) the limitations of this approach:
If the analysis is successful then it detected no incorrect behaviour, but this does not mean that correct behaviour is guaranteed. The analysis attempts to detect common bugs but it does not offer 100% coverage. Additionally, it does not test the following:
- Your repository must perform durable writes. Once a blob has been written it must remain in place until it is deleted, even after a power loss or similar disaster.
- Your repository must not suffer from silent data corruption. Once a blob has been written, its contents must remain unchanged until it is deliberately modified or deleted.
- Your repository must behave correctly even if connectivity from the cluster is disrupted. Reads and writes may fail in this case, but they must not return incorrect results.
specifically call out support for specific S3 providers
Right, we call out MinIO here in these docs and redirect everyone else to contact their supplier for the relevant support rather than us.
There was a problem hiding this comment.
...and testing durability, consistency and erroneous behavior is indeed not something we can do as part of an API call, I understand the conundrum 😅
Thanks for your patience here @DaveCTurner , this is clear :)
3 participants
Mention EC2 instance roles as well as ECS roles and K8s service accounts.
Mention reliability of S3-compatible storage as well as consistency & performance.