Small improvements to repo analysis docs #4413
Conversation
* Reflows the text so it's all sentence-per-line. * Improves the one-line summary at the top of the article. * Explains why you must run increasingly large analyses rather than just accepting the first run. * Expands the docs about why failures are bad even if snapshots appear to work. * Mentions verifying the reference implementation before reporting ES bugs.
|
Following you can find the validation results for the API you have changed.
You can validate this API yourself by using the |
|
Following you can find the validation results for the API you have changed.
You can validate this API yourself by using the |
| * Perform the analyses using a multi-node cluster of a similar size to your production cluster so that it can detect any problems that only arise when the repository is accessed by many nodes at once. | ||
| * | ||
| * If the analysis fails, Elasticsearch detected that your repository behaved unexpectedly. | ||
| * This usually means you are using a third-party storage system with an incorrect or incompatible implementation of the API it claims to support. | ||
| * If so, this storage system is not suitable for use as a snapshot repository. | ||
| * Repository analysis triggers conditions that occur only rarely when taking snapshots in a production system. | ||
| * Snapshotting to unsuitable storage may sometimes appear to work correctly most of the time despite repository analysis failures. |
There was a problem hiding this comment.
"sometimes" or "most of the time"?
There was a problem hiding this comment.
60% of the time, it happens every time 😁
Removed the "sometimes". The original was technically what I wanted to say, in that some broken setups will appear to work mostly ok whereas other broken setups will be reliably broken. But it's awkward, and the "may" is conditional enough.
Thank you for reviewing! They are generated, but we currently commit the result, so it makes sense to update the generation as part of the pull request. David followed the contribution guidelines here. I agree that it is confusing and makes the repository slower to clone, so we'll move away from this when migrating the specification to Elasticsearch. |
|
Following you can find the validation results for the API you have changed.
You can validate this API yourself by using the |
* Explains why you must run increasingly large analyses rather than just accepting the first run. * Expands the docs about why failures are bad even if snapshots appear to work. * Mentions verifying the reference implementation before reporting ES bugs. Backport to `8.19` of elastic/elasticsearch-specification#4413
* Explains why you must run increasingly large analyses rather than just accepting the first run. * Expands the docs about why failures are bad even if snapshots appear to work. * Mentions verifying the reference implementation before reporting ES bugs. Backport to `8.19` of elastic/elasticsearch-specification#4413
* Explains why you must run increasingly large analyses rather than just accepting the first run. * Expands the docs about why failures are bad even if snapshots appear to work. * Mentions verifying the reference implementation before reporting ES bugs. Backport to `8.19` of elastic/elasticsearch-specification#4413
* Explains why you must run increasingly large analyses rather than just accepting the first run. * Expands the docs about why failures are bad even if snapshots appear to work. * Mentions verifying the reference implementation before reporting ES bugs. Backport to `8.19` of elastic/elasticsearch-specification#4413
Reflows the text so it's all sentence-per-line.
Improves the one-line summary at the top of the article.
Explains why you must run increasingly large analyses rather than just accepting the first run.
Expands the docs about why failures are bad even if snapshots appear to work.
Mentions verifying the reference implementation before reporting ES bugs.