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

store: Added test for consistency delay filter, defaulted to 0. #2159

Merged
merged 1 commit into from
Feb 20, 2020

Conversation

bwplotka
Copy link
Member

Signed-off-by: Bartlomiej Plotka [email protected]

@bwplotka
Copy link
Member Author

cc @khyatisoneji : We missed a unit test for that.

Also moving to default consistency delay to 0. This is to not surprise users. In fact you only need this when you have eventually consistent object storage, am I right? (:

@bwplotka bwplotka force-pushed the consistency-delay branch 2 times, most recently from 471b170 to eda3b2f Compare February 20, 2020 13:47
@brancz brancz merged commit 021f623 into master Feb 20, 2020
@brancz brancz deleted the consistency-delay branch February 20, 2020 15:25
@brancz
Copy link
Member

brancz commented Feb 20, 2020

Should we have documentation on what appropriate values might be for various providers? For example with AWS S3's read-after-write consistency we have no problem with a consistency delay of 0 is my understanding.

@bwplotka
Copy link
Member Author

Yes. At least.. we did not notice anything wrong with S3. Eventual consistency can have really different tmp side effects. In theory we kind of DON'T hit the thing mentioned by S3 as the one that triggers eventual consistent behavior: a HEAD against the path that is later used. We only do that for meta.json:

ok, err := s.bucket.Exists(ctx, path.Join(m.ULID.String(), block.MetaFilename))

So it's fine I guess. But all of this is not well documented by S3. I think having some small consistency delay might be helpful just in case. Also, this is still crippled as we check block creation time, not the actual modification time of file.

@metalmatze
Copy link
Contributor

As these are tests nothing needs to be added to the Changelog, correct? Just rebase the release branch to include it?!

@bwplotka
Copy link
Member Author

bwplotka commented Feb 20, 2020

Yup. We already have entry for it.

@brancz
Copy link
Member

brancz commented Feb 20, 2020

In theory we kind of DON'T hit the thing mentioned by S3 as the one that triggers eventual consistent behavior: a HEAD against the path that is later used. We only do that for meta.json:

yeah I'm saying writing down expected things and correcting them as we learn also helps the community and users :)

@GiedriusS
Copy link
Member

Makes sense to me, this is not to surprise the users. OTOH there's no bad side effect if we will start serving data from remote object storage only after 30 minutes except that it might not be intuitive. All in all, let's opt for the principle of least surprise but some docs would indeed be nice 👍

vankop pushed a commit to monitoring-tools/thanos that referenced this pull request Feb 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants