-
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
Loki: Common Config #4347
Loki: Common Config #4347
Conversation
…outside of this package. create a pkg/cfg which handles building the Loki config, this is created separately from pkg/util (which is Apache 2 licensed) to maintain proper separations of AGPL and Apache 2 code Update the main.go for several of the apps with the refactoring
476fa1e
to
cb9c670
Compare
pkg/cfg/cfg.go
Outdated
|
||
// Apply all our custom logic here to set values in the Loki config from values in the common config | ||
// FIXME this is just an example showing how we can use values from the common section to set values on the Loki config object | ||
r.StorageConfig.BoltDBShipperConfig.SharedStoreType = r.Common.Store |
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.
Here we can do anything needed to map common
configs to the Loki configs
pkg/cfg/common/common.go
Outdated
package common | ||
|
||
type Config struct { | ||
Store string // This is just an example, but here we should define all the 'common' config values used to set other Loki values. |
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.
Here we can define the common
config struct
I'd like to see a ring config make it into common. Redefining the same ring kv config for each component is tedious, since most deployments typically use 1 kv type for all their rings. |
@slim-bean does this just create a common config, or does it also set some reasonable defaults in that common config? I'm wondering if we need to leave (My rough glance as this PR suggests it only puts the common config in place, but doesn't redefine any of the defaults). |
@09jvilla this was mostly just a POC to make sure this mechanism would work. We can do whatever we want with whatever defaults we want in here. So we could definitely add some code for setting the |
I think this mechanism makes sense. If that's fine with you @slim-bean then i'll push into this PR's branch to add more common configs? |
Signed-off-by: Trevor Whitney <[email protected]>
Looks reasonable to me 👍 |
Signed-off-by: Trevor Whitney <[email protected]>
Signed-off-by: Trevor Whitney <[email protected]>
Signed-off-by: Trevor Whitney <[email protected]>
Signed-off-by: Trevor Whitney <[email protected]>
@slim-bean @replay @owen-d I refactored the implementation a bit, added tests, and added an example of how this will work using a common path prefix config. Let me know what you think, thanks! |
Signed-off-by: Trevor Whitney <[email protected]>
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.
LGTM
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.
A few nits, then LGTM
config := ConfigWrapper{} | ||
fs := flag.NewFlagSet(t.Name(), flag.PanicOnError) | ||
|
||
file, err := ioutil.TempFile("", "config.yaml") |
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.
It'd be good to remove this file via defer
when the test completes.
return config, defaults | ||
} | ||
|
||
t.Run("common path prefix config", func(t *testing.T) { |
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.
nit: These look like good candidates for table tests.
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.
TBH, I find table tests harder to read and understand. I think they're great for checking relationships between inputs and outputs that resemble a truth table, but for something like this I think it would make it more difficult to understand why a test fails.
For example, if the test testing that command line input takes precedence fails, the output will give me a line number for that assertion. When I go to that assertion, it won't be immediately clear why it failed because we'll just be passing tt.args
to the function. In order to determine which input actually caused the failure I would have to copy the name of the failing test from my terminal and then grep for that in the array of inputs to correlate the failure to the correct input data.
Instead, structuring the test like this, all shared logic is still extracted to the testContext
function, but now when a test fails I'm taken to a line with the failing input data right there above it (ie. args := []string{"-foo", "bar"}
). IMO this makes it a lot easier to quickly understand why a test fails. Sure it may be a few more lines, but I will trade verbosity for readability all day, especially in tests.
Thoughts?
Co-authored-by: Owen Diehl <[email protected]>
Co-authored-by: Owen Diehl <[email protected]>
Co-authored-by: Owen Diehl <[email protected]>
Signed-off-by: Trevor Whitney <[email protected]>
This PR sets out to add a new
common
section to Loki's config file which is to be used for simplifying Loki's config for most use cases by applying a set of opinionated defaults for as many config options as possible covering a vast majority of Loki use cases.Checklist