-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Allow instantiating extensions in separate configs #8394
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
Comments
github-merge-queue bot
pushed a commit
that referenced
this issue
Mar 4, 2025
Koanf's default merging strategy currently overrides static values such as slices, numbers, and strings. However, lists of components should be treated as a special case. This pull request introduces a new command line option to allow for merging lists instead of discarding the existing ones. With this new merging strategy: - All the lists are merged rather than replaced. - The merging logic is name-aware, meaning that if components with the same name appear in both lists, they will only appear once in the final merged list. <!-- Issue number if applicable --> #### Link to tracking issue Related issues: - #8754 - #8394 - #10370 <!--Describe what testing was performed and which tests were added.--> #### Testing - Added <!--Describe the documentation added.--> #### Documentation - Added under readme. ##### Example Consider the following configs, ```yaml # main.yaml receivers: otlp/in: processors: batch: exporters: otlp/out: extensions: file_storage: service: pipelines: traces: receivers: [ otlp/in ] processors: [ batch ] exporters: [ otlp/out ] extensions: [ file_storage ] ``` ```yaml # extra_extension.yaml extensions: healthcheckv2: service: extensions: [ healthcheckv2 ] ``` If you run the collector with following command, ``` otelcol --config=main.yaml --config=extra_extension.yaml --feature-gates=-confmap.enableMergeAppendOption ``` then the final configuration after config resolution will look like following: ```yaml # main.yaml receivers: otlp/in: processors: batch: exporters: otlp/out: extensions: file_storage: healthcheckv2: service: pipelines: traces: receivers: [ otlp/in ] processors: [ batch ] exporters: [ otlp/out ] extensions: [ file_storage, healthcheckv2 ] ``` For backward compatibly, the default behaviour is **not** to merge lists. Users who want to explicitly merge lists can enable the command line option. Note: I’d appreciate your feedback on this 🙏
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
There is currently no way to easily instantiate extensions across multiple configuration sources. The default behavior in koanf is to overwrite slices when merging multiple maps. This results in behavior where the
service.extensions
key will be overridden and take the value of the final source if it is set multiple times.Take the following two configuration files:
If I start the Collector with the following, only the zpages extension will be started.
The effective config will look like:
Describe the solution you'd like
At a minimum, provide a naming scheme similar to what we provide for pipelines to allow config sources to instantiate extensions they define. This could look like:
Describe alternatives you've considered
A more comprehensive solution could be to override the default koanf merging strategy to support merging slices. I would propose the following rules for merging slices:
The caveat with changing this behavior is that it would be more difficult to set slice values to empty lists, which would now require setting to
nil
(or another primitive value) before setting them to an empty list.We could also simply recommend that extensions are all instantiated in a single file, but in my view this is not a good solution.
Additional context
It's possible I've missed an existing mechanism for this, but I've looked through the code and docs and don't see an any way to accomplish this. If I've missed something we should make it more visible.
The text was updated successfully, but these errors were encountered: