-
Notifications
You must be signed in to change notification settings - Fork 1.7k
[confmap]- Implement yaml tags based strategy for merge append mode #13551
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
base: main
Are you sure you want to change the base?
Changes from all commits
a80f16f
48d9ba8
d056c33
46b4be3
9afe416
560097f
28c1dcc
106b511
56f7b40
30d8338
92b6e99
76d52e9
d8359fc
ca24630
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
# Use this changelog template to create an entry for release notes. | ||
|
||
# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
change_type: enhancement | ||
|
||
# The name of the component, or a single word describing the area of concern, (e.g. otlpreceiver) | ||
component: pkg/confmap | ||
|
||
# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
note: Add YAML tag based list merging strategy. | ||
|
||
# One or more tracking issues or pull requests related to the change | ||
issues: [8754] | ||
|
||
# (Optional) One or more lines of additional information to render under the primary note. | ||
# These lines will be padded with 2 spaces and then inserted directly into the document. | ||
# Use pipe (|) for multiline entries. | ||
subtext: | ||
|
||
# Optional: The change log or logs in which this entry should be included. | ||
# e.g. '[user]' or '[user, api]' | ||
# Include 'user' if the change is relevant to end users. | ||
# Include 'api' if there is a change to a library API. | ||
# Default: '[user]' | ||
change_logs: [] |
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -96,11 +96,32 @@ The `Resolve` method proceeds in the following steps: | |
#### (Experimental) Append merging strategy for lists | ||
|
||
You can opt-in to experimentally combine slices instead of discarding the existing ones by enabling the `confmap.enableMergeAppendOption` feature flag. Lists are appended in the order in which they appear in their configuration sources. | ||
This will **not** become the default in the future, we are still deciding how this should be configured and want your feedback on [this issue](https://github.com/open-telemetry/opentelemetry-collector/issues/8754). | ||
This lets you combine slices from multiple configuration sources, with control over ordering, duplicates, and targeted merge paths using YAML tags or URI query parameters. | ||
|
||
#### How It Works | ||
|
||
Annotate any list in your YAML config with a custom tag (URI-style parameters) to specify how it should be merged. | ||
|
||
**Tag format:** | ||
`!mode=append&duplicates=false` | ||
|
||
**Options:** | ||
- `mode`: `append` (default) | ||
- `duplicates`: `true` or `false` (default: `false`) | ||
- Setting this to `true` allows duplicate entries in the final list. | ||
Comment on lines
+110
to
+111
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this something that we could add later or is it required from the start? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can add this later. For now, we can say that we "skip duplicates" |
||
|
||
> [!WARNING] | ||
> Specifying incorrect values in YAML tags will result in fallback to the default behavior. | ||
Comment on lines
+113
to
+114
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there any way to fail fast in this case instead of falling back to the default behavior? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. I'll update the function to validate tags and return error if invalid options are specified. |
||
|
||
#### Default Behavior (Override) | ||
|
||
If you do **NOT** specify any merge options or tags, lists are merged using the default override behavior (the last config wins). | ||
|
||
##### Example | ||
Consider the following configs, | ||
|
||
Suppose you have the following configurations: | ||
|
||
**main.yaml** | ||
```yaml | ||
# main.yaml | ||
receivers: | ||
|
@@ -126,24 +147,20 @@ service: | |
extensions: [ file_storage ] | ||
``` | ||
|
||
|
||
**extra_extension.yaml** | ||
```yaml | ||
# extra_extension.yaml | ||
extensions: | ||
healthcheckv2: | ||
|
||
service: | ||
extensions: [ healthcheckv2 ] | ||
pipelines: | ||
traces: | ||
extensions: !mode=append [healthcheckv2] | ||
``` | ||
|
||
If you run the Collector with following command, | ||
``` | ||
If you run the Collector with: | ||
```bash | ||
otelcol --config=main.yaml --config=extra_extension.yaml --feature-gates=confmap.enableMergeAppendOption | ||
``` | ||
then the final configuration after config resolution will look like following: | ||
|
||
The result after merging will be: | ||
```yaml | ||
# main.yaml | ||
receivers: | ||
|
@@ -169,10 +186,10 @@ service: | |
extensions: [ file_storage, healthcheckv2 ] | ||
``` | ||
|
||
Notice that the `service::extensions` list is a combination of both configurations. By default, the value of the last configuration source passed, `extra_extension`, would be used, so the extensions list would be: `service::extensions: [healthcheckv2]`. | ||
Notice how the `service::extensions` list is a combination of both configurations, preserving both values. | ||
|
||
> [!NOTE] | ||
> By enabling this feature gate, all the lists in the given configuration will be merged. | ||
> By enabling this feature gate, only the lists annotated with YAML merge tags will be merged according to your specified strategy. Unannotated lists will continue to use the default override behavior (last list wins). | ||
|
||
### Watching for Updates | ||
After the configuration was processed, the `Resolver` can be used as a single point to watch for updates in the | ||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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 is a bit confusing, what does it mean for this to be the default? I guess this is the "default for annotated lists"?
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.
Yes. I'll make this verbose to remove the ambiguity.