-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Add common ring configuration #4617
Conversation
Co-Authored-By: Dylan Guedes <djmgguedes@gmail.com>
pkg/loki/config_wrapper.go
Outdated
// append the loopback after checking if the default is enabled, as it mutates the current | ||
appendLoopbackInterface(r, defaults) | ||
|
||
numTokens := 128 //this is the default used by the ingester and ruler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@owen-d per your comment on @DylanGuedes's original PR, do you think we should use 512 here instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should be overwriting these at all. Extra fields (i.e. num_tokens) can still be reconfigured by setting the ingester ring tokens manually, but I don't think we should be overriding them here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, so just leave that one blank for now, I'm in agreement with that.
pkg/loki/config_wrapper.go
Outdated
r.Ingester.LifecyclerConfig.TokensFilePath = f | ||
func useCommonRingConfig(r, defaults *ConfigWrapper) { | ||
// if the default ingester config is detected, then it's safe to override with the common config | ||
shouldOverrideIngester := reflect.DeepEqual(r.Ingester.LifecyclerConfig, defaults.Ingester.LifecyclerConfig) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@owen-d per your comment on @DylanGuedes's original PR, would you like to see this DeepEqual
check applied to all ring overrides? The reason why we may not need to do that is because after this ApplyDynamicConfig
function runs, we the parse the config file and command line args again. So, if someone is not using the default, they must have provided configs in one of those 2 places, and thus they will get applied and overrides any dynamic configs we applied.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. I don't think it's necessary 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, since in such a scenario the configs would be applied again, maybe this whole shouldOverrideIngester
isn't necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, and just always override the ingester. that's a good point. I believe we have test coverage for that case so I'll try it out
@@ -82,6 +82,27 @@ func (cfg *RingConfig) ToLifecyclerConfig(numTokens int) (ring.BasicLifecyclerCo | |||
}, nil | |||
} | |||
|
|||
func CortexLifecyclerConfigToRingConfig(cfg ring.LifecyclerConfig) RingConfig { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be dskit instead of cortex?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we will do that eventually, but we've not yet migrated to the dskit
ring.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some initial feedback, thanks for picking this up!
pkg/loki/config_wrapper.go
Outdated
// append the loopback after checking if the default is enabled, as it mutates the current | ||
appendLoopbackInterface(r, defaults) | ||
|
||
numTokens := 128 //this is the default used by the ingester and ruler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should be overwriting these at all. Extra fields (i.e. num_tokens) can still be reconfigured by setting the ingester ring tokens manually, but I don't think we should be overriding them here.
pkg/loki/config_wrapper.go
Outdated
r.Ingester.LifecyclerConfig.TokensFilePath = f | ||
func useCommonRingConfig(r, defaults *ConfigWrapper) { | ||
// if the default ingester config is detected, then it's safe to override with the common config | ||
shouldOverrideIngester := reflect.DeepEqual(r.Ingester.LifecyclerConfig, defaults.Ingester.LifecyclerConfig) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. I don't think it's necessary 👍
func applyIngesterRingConfig(r *ConfigWrapper, defaults *ConfigWrapper) error { | ||
if reflect.DeepEqual(r.Ingester.LifecyclerConfig.InfNames, defaults.Ingester.LifecyclerConfig.InfNames) { | ||
appendLoopbackInterface(r) | ||
// 1. Gives preference to any explicit ring config set. For instance, if the user explicitly configures Distributor's ring, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be explicit > common > memberlist
. Using the ingester
's ring was a stopgap put in place recently and meant to accomplish what the new common.ring
will, so it's not something we'll need to retain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I can imagine users being confused due to their different rings not using default values listed in the documentation (instead, such rings would be using the ingester config, which they might not even realize).
pkg/loki/config_wrapper.go
Outdated
ingesterRingCfg := util.CortexLifecyclerConfigToRingConfig(r.Ingester.LifecyclerConfig) | ||
numTokens := r.Ingester.LifecyclerConfig.NumTokens | ||
|
||
// we're using the ingester config here, so never need to override it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, I was thinking since you are passing the ingester
, wouldn't it be fine to allow overriding the ingester? In such a scenario you'd be overriding the ingester with the ingester itself, so looks fine.
edit: In conclusion, maybe we can remove the whole third param
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I like that idea, I'm going to look into removing the whole third param
Thank you for picking this one Trevor, and great work with the memberlist integration. 😄 I left a few nitpicking comments but LGTM. |
pkg/loki/config_wrapper.go
Outdated
} else { | ||
// neither common ring nor memberlist set, use ingester ring configuration for all rings | ||
useIngesterRingConfig(r, defaults) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should apply the ingester configs to any other ring.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we make the decision, which I agree is more straight forward, we run the risk of 2.4 being a breaking release to people with existing configs, as it introduces a few new rings that are required
Co-authored-by: Dylan Guedes <djmgguedes@gmail.com>
ffa2c88
to
82fe79e
Compare
@@ -76,11 +77,15 @@ func (c *ConfigWrapper) ApplyDynamicConfig() cfg.Source { | |||
r.QueryScheduler.UseSchedulerRing = true | |||
} | |||
|
|||
applyPathPrefixDefaults(r, defaults) | |||
if err := applyIngesterRingConfig(r, &defaults); err != nil { | |||
applyPathPrefixDefaults(r, &defaults) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw, since applyPathPrefixDefaults
is being invoked before applyDynamicRingConfigs
, the check reflect.DeepEqual(r.CompactorConfig.CompactorRing, defaults.CompactorConfig.CompactorRing)
will always be false I think
edit: my bad, I meant applyTokensFilePath
instead of applyPathPrefixDefaults
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does applyPathPrefixDefaults
modify the compactor's ring? I see it modifying the working directory, but I'm missing the impact on the ring?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I completely confused the function names 😂 I was referring to applyTokensFilePath
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work navigating that complexity, LGTM
What this PR does / why we need it:
This work finished what @DylanGuedes started with the common ring config and replaces #4610, which has a much better description.
Checklist
CHANGELOG.md
about the changes.