-
Notifications
You must be signed in to change notification settings - Fork 1.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
[confmap] Deprecate expandconverter #10510
[confmap] Deprecate expandconverter #10510
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #10510 +/- ##
==========================================
+ Coverage 91.37% 91.64% +0.26%
==========================================
Files 406 406
Lines 19007 18998 -9
==========================================
+ Hits 17368 17411 +43
+ Misses 1282 1227 -55
- Partials 357 360 +3 ☔ View full report in Codecov by Sentry. |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
The same comment here as in #10723. We need to move the |
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
…elmuth/opentelemetry-collector into deprecate-expandconverter
The failed test will be handled by #10508. |
Co-authored-by: Dmitrii Anoshin <anoshindx@gmail.com>
…0508) #### Description This PR promotes the `confmap.unifyEnvVarExpansion` feature gate to stable and sets a `ToVersion` of `v0.106.0`, anticipating that the gate be completely removed in that version. We should weigh if switching the Stable should be done in `v0.105.0` or if it needs more time in `Beta` to give users more time to switch. Delaying promotion to `Stable` delays confmap 1.0. If we merge this we need to commit to merging #10510 in the same release. #### Link to tracking issue Related to #10161 Related to #7111 Related to #8215 --------- Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
Merged #10508. Please rebase |
# 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: [api] |
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.
change_logs: [api] | |
change_logs: [user] |
I'm tempted to say that we should include this in the user-facing changelog since we encourage users to build their own Collector binaries.
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.
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.
We need to define the end user here :) I'm ok with any. We struggle on the same Q for madatagen "users".
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.
Potentially, we can have 2 more changelogs: ocb
and mdatagen
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 believe user
denotes those who run the collector and api
denotes those who import libraries into their code.
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'm merging as is for now. Feel free to continue the discussion and we can change this line if needed
Hey, bumping this because removing this expansion seems to have broken the capability for YAML to have predefined chunks which can be re-used across multi-organization support teams. I'll make an issue and try to repro, but the tl;dr is that we used to do something like this: ...
filelog:
<<: ${internal:filelog-defaults}
include:
- some additional include This use to work as a way to allow users to merge predefined configuration with their own overrides and no longer functions. I'm fairly confident it's due to this removal. Is there any hope to address this issue or is it just an unsupported feature? |
@Erog38 Please file an issue with a repro and we can take a look :) |
Description
This PR deprecates
expandconverter
and removes its use fromotelcoltest.LoadConfig
and OCB.This cannot be merged until the
confmap.unifyEnvVarExpansion
feature gate is made stable.Link to tracking issue
closes #10161
closes #7111
closes #8215