Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify Blobstore Consistency Check in Tests #73992

Conversation

original-brownbear
Copy link
Member

With work to make repo APIs more async incoming in #73570
we need a non-blocking way to run this check. This adds that async
check and removes the need to manually pass executors around as well.

With work to make repo APIs more async incoming in elastic#73570
we need a non-blocking way to run this check. This adds that async
check and removes the need to manually pass executors around as well.
@original-brownbear original-brownbear added >test Issues or PRs that are addressing/adding tests :Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs v8.0.0 v7.14.0 labels Jun 10, 2021
@elasticmachine elasticmachine added the Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. label Jun 10, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (Team:Distributed)

Copy link
Contributor

@fcofdez fcofdez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, one orthogonal comment. Also +1 to what Francisco said.

@@ -113,15 +112,13 @@ public static void assertConsistency(BlobStoreRepository repository, Executor ex
assertIndexUUIDs(repository, repositoryData);
assertSnapshotUUIDs(repository, repositoryData);
assertShardIndexGenerations(blobContainer, repositoryData.shardGenerations());
return null;
} catch (AssertionError e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we're catching the AssertionError here in order to re-throw it on the calling thread so that we can use this within assertBusy() for the third-party tests that allow for S3 to be eventually-consistent. Do we need that any more, now that S3 is properly consistent?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question ... I guess you could make the same argument for other eventual consistency code (mainly EventuallyConsistentMockRepository and just drop that stuff as well. But I always figured that we may still have other S3 compatible implementations out there in the wild that are eventually consistent and so it's nice to have this stuff in tests for third party testing? (not sure ... I don't know of any and would also be happy to drop all of it to save some LoC :))

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could reasonably say a third (fourth?) party implementation that has weaker consistency than the real S3 is not compatible. The repo analysis API fails on inconsistent listings:

final RepositoryVerificationException repositoryVerificationException = new RepositoryVerificationException(
request.repositoryName,
"expected blobs " + missingBlobs + " missing in [" + request.repositoryName + ":" + blobPath + "]"
);
logger.debug("failing due to missing blobs", repositoryVerificationException);
fail(repositoryVerificationException);

Copy link
Member Author

@original-brownbear original-brownbear Jun 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair point, I'll open a follow-up that drops all these tests in a bit then :)

@original-brownbear
Copy link
Member Author

Thanks Francisco and David!

@original-brownbear original-brownbear merged commit 5249540 into elastic:master Jun 10, 2021
@original-brownbear original-brownbear deleted the simplify-repo-consistency-check branch June 10, 2021 14:12
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Jun 13, 2021
With work to make repo APIs more async incoming in elastic#73570
we need a non-blocking way to run this check. This adds that async
check and removes the need to manually pass executors around as well.
original-brownbear added a commit that referenced this pull request Jun 13, 2021
With work to make repo APIs more async incoming in #73570
we need a non-blocking way to run this check. This adds that async
check and removes the need to manually pass executors around as well.
@original-brownbear original-brownbear restored the simplify-repo-consistency-check branch April 18, 2023 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. >test Issues or PRs that are addressing/adding tests v7.14.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants