-
Notifications
You must be signed in to change notification settings - Fork 528
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
Overrides module refactor #2688
Conversation
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! This must have been a ton of work to track down all the compilation errors 😅
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.
Docs look good. Thank you for adding them.
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.
Looks good to me ✅
Can't approve since I also have changes in here though + I think having another review to make sure the new overrides struct is reasonable would be nice.
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.
This looks pretty good to me. A little tough to review the toLegacy
bits due to the high number of config options. Have we been able to test this out somewhere? A little nervous to merge on a Friday.
@@ -49,7 +49,7 @@ type Config struct { | |||
Ingester ingester.Config `yaml:"ingester,omitempty"` | |||
Generator generator.Config `yaml:"metrics_generator,omitempty"` | |||
StorageConfig storage.Config `yaml:"storage,omitempty"` | |||
LimitsConfig overrides.Limits `yaml:"overrides,omitempty"` | |||
Overrides overrides.Config `yaml:"overrides,omitempty"` |
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 like that this lines up a little more consistently.
I've tested it locally, but I can deploy it somewhere if 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.
Code changes look good to me. I think we will need to do some more docs changes to remove uses of the old structure, or did you want to do these in a separate PR?
The following pages need updates and there might be more examples with overrides:
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.
This looks reasonable to me. Do we have thoughts about how to transition our jsonnet to the new approach?
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.
The code changes look good to me
But I agree with @kvrhdn that the docs for the overrides should be updated. I think it would be OK to do this in an extra PR though
Hi folks, I've updated all the docs. I'll open a new issue to handle the migration of jsonnet. |
@mapno : How/where do I put this in the Tempo Distributed Helm chart? Currently working with the
I get errors on startup similar to this:
|
Hey. Unfortunately, this PR is required to use the new format grafana/helm-charts#2825. Let's see if we can get a final approval. |
Thanks for the update! Didn't realize the Tempo Distributed Helm chart wasn't equipped to handle the new overrides format (aside from me trying to force it to happen). I may stick with the 'legacy' format for now in order to keep things moving on our side. |
Dear Can someone please give an example on how to use this new overrides config? I placed it in the conf/tempo.yaml It always keeps saying defaults is not found on the legacyoverrides. The config I try to accomplice looks like this.
|
What this PR does:
Follow up to #2638
The
Limits
struct has a mixed responsibility:When it is used in the top-level
App
struct it contains default values for the limits and configuration for per-tenant overrides. But whenLimits
is used by the runtime config manager it contains per tenant values of the limits.The dual purpose of
Limits
is awkward and confusing.Furthermore, the overrides module has outgrown its original scope of providing limits to Tempo components, to hosting any kind of dynamic configuration that can be modified at runtime. In the same config block we have ingestion limits like
ingestion_rate_limit_bytes
, metrics-generator config such asmetrics_generator_ring_size
, and (soon™️) storage config with the introduction of #2551.All of this makes for a complex config structure, with overly long param names (eg.
metrics_generator_processor_service_graphs_enable_client_server_prefix
), and unclear scope.This PR addresses this by creating a
Config
struct that is explicitly intended to configure the overrides module, ensuring theLimits
struct can focus on holding limits only. It also adds indentation to the parameters, making them easier to read and write.These has effects on the tempo config file and the per tenant overrides file.
Old config:
New config:
Which issue(s) this PR fixes:
Fixes #2641
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]