-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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] Unify behavior of ${env:ENV}
and ${ENV}
#10161
Comments
${env:ENV} and
${ENV}`${env:ENV}
and ${ENV}
@mx-psi I see a couple approaches.
I've experimented with 2 and think it would be workable. It would take care of this issue and #8215 at once. It did feel a little messy but there are probably ways to share code between the 2 places. I would also be ok with option 4, as it provides a lot of flexibility. Option 3 is pretty simple as well. |
Option 4 feels the cleanest to me. I think we should do it without the awareness of any of the Providers by prepending the default schema to the URI when the URI is given to the Provider, like the Resolver currently does with files passed to |
Ya that would work. I don't love the idea of messing with the incoming values, but if we already have precedence I can be ok with it.
I think this is an option, but not required for 1.0 |
Agreed that option 4 feels like the cleanest. If we go with (4), for now I don't think we need to make this configurable anywhere other than the Go API, but we can open the door to make this configurable in the future by end-users |
Agreed. I'll start work on option 4. I try to do this and #7111 in one. |
#### Description This PR adds support for expanding `${}` syntax when no schema is provided by allowing Resolver to use a default provider. In a followup PR I'll update otelcol with a feature gate that allow switching between a default envProvider and the expandconverter. #### Link to tracking issue Related to #10161 Related to #7111 #### Testing Added unit tests #### Documentation Added godoc strings --------- Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
As decided on #9854, we want to unify the behavior of
${env:ENV}
and${ENV}
. Currently, each has a different behavior: the${ENV}
syntax does not do any YAML parsing, while the${env:ENV}
syntax does parse the contents as YAML. We want to unify both and make them have the same behavior, described in RFC #9854.One approach for this is to have some 'default' confmap provider used by the
${..}
syntax, and control what provider is used (aexpandconverter
provider or theenv
provider) through a feature gate.cc @TylerHelmuth
The text was updated successfully, but these errors were encountered: