enforce sharding defaults in period configs #2332
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does:
This fixes a bug where the default shard factors were not set properly on
PeriodConfigs
. It caused us to never update the period config’s shard factor (although the derived Schema, which is used in the store, has the default shard values applied — 16 starting in v10+).I introduced this bug while addressing the following:
#1878 (comment)
Discovery
We discovered this bug when we tried to enable
querier.parallelise-shardable-queries
. It effectively turned that code path into a no-op because it didn't register any shard-ablePeriodConfigs
(we don't specify overrides and use the derived default).The Fix
func (cfg *PeriodConfig) applyDefaults()
function which mutates the associatedPeriodConfig
by applying default values (currently only shard factor for appropriate schemas).PeriodConfig.Validate()
This should ensure that once validated , configs are safe for further use.
/cc @gouthamve @cyriltovena
Signed-off-by: Owen Diehl ow.diehl@gmail.com