Skip to content
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] Add featuregate to use stable expansion rules #10259

Conversation

TylerHelmuth
Copy link
Member

Description

Add a feature gate that provides access to stable expansion rules. When enabled:

  1. env is used as the default scheme
  2. expandconverter is not used, which means $ENV syntax is no longer expanded

Link to tracking issue

Related to #10161
Related to #8215
Related to #7111

Testing

Tested manually locally

@TylerHelmuth TylerHelmuth force-pushed the confmap-add-expand-featuregate branch from 399d98f to 26a6d75 Compare May 30, 2024 17:32
Copy link

codecov bot commented May 30, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.53%. Comparing base (7dfb57b) to head (a123337).

Additional details and impacted files
@@           Coverage Diff           @@
##             main   #10259   +/-   ##
=======================================
  Coverage   92.53%   92.53%           
=======================================
  Files         388      388           
  Lines       18317    18317           
=======================================
  Hits        16949    16949           
  Misses       1022     1022           
  Partials      346      346           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@TylerHelmuth TylerHelmuth marked this pull request as ready for review May 30, 2024 17:49
@TylerHelmuth TylerHelmuth requested a review from a team as a code owner May 30, 2024 17:49
Comment on lines 43 to 51
{{ if .Distribution.SupportsConfmapFactories }}
if confmap.UseStableExpansionRules.IsEnabled() {
set.ConfigProviderSettings.ResolverSettings.DefaultScheme = "env"
} else {
set.ConfigProviderSettings.ResolverSettings.ConverterFactories = []confmap.ConverterFactory{
expandconverter.NewFactory(),
}
}
{{- end}}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mx-psi @evan-bradley this solution has the downside that it will only apply to people that use ocb. Is that ok?

Does it need to live in otelcol, like in NewCommand, and be allowed to mess with the incoming settings, ignoring any configured expandconverter?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If possible, this is the process I think would work best:

  1. Implement the feature gate in NewCommand/NewCollector/etc. with what you have here.
  2. Turn the feature gate on by default.
  3. Allow configuring the default scheme in an ocb manifest.
  4. Remove the feature gate and the expand converter from ocb in one go, since there's no way to configure converters in the ocb manifest right now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the two behaviors can coexist, I don't think we should remove a configured expand converter.

Copy link
Member Author

@TylerHelmuth TylerHelmuth May 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this again I propose a alternative:

Since this is a change to how CollectorSettings is configured, we handle the transition for only our own usage (ocb) - anyone using NewCommand is responsible for updating their own CollectorSettings once expandconverter is deprecated.

This approach would mean moving the featuregate into the main.go generated by ocb, deprecating expandconverter and then as part of that deprecation following a standard feature gate process.

This approach saves us the trouble of guessing how other users of NewCommand want to handle the deprecation of the expandconverter while at the same time enforcing our own Provider expectations established in the rfc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would first have to handle this TODO first, where we start requiring incoming CollectorSettings to have the providers/converts supplied, making NewCommand more dependent on a full set of settings when invoked.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@evan-bradley @mx-psi @codeboten I am still working towards this PR but trying to unblock/simplify it by working on #10290 first.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this some more, I believe by moving the feature gate to builder and only controlling our own use of expandconverter allows this PR and #10359 to happen in parallel.

Copy link
Contributor

@codeboten codeboten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest moving the feature gate to a different package to prevent all the imports this is causing

@TylerHelmuth TylerHelmuth force-pushed the confmap-add-expand-featuregate branch 2 times, most recently from 0e8fb5d to 36431dc Compare May 31, 2024 14:32
@TylerHelmuth TylerHelmuth force-pushed the confmap-add-expand-featuregate branch from 36431dc to e8a88ff Compare May 31, 2024 14:36
Copy link
Contributor

@codeboten codeboten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lint fails:

/home/runner/work/opentelemetry-collector/opentelemetry-collector/.tools/golangci-lint run
Error: configprovider.go:145:51: SA1019: expandconverter.NewFactory is deprecated: [v0.102.0] Expanding $ENV is no longer supported. To expand ${} using env vars use DefaultScheme="env" or the otelcol.useStableExpansionRules feature gate. (staticcheck)
			ConverterFactories: []confmap.ConverterFactory{expandconverter.NewFactory()},
			                                               ^
Error: command_test.go:57:52: SA1019: expandconverter.NewFactory is deprecated: [v0.102.0] Expanding $ENV is no longer supported. To expand ${} using env vars use DefaultScheme="env" or the otelcol.useStableExpansionRules feature gate. (staticcheck)
				ConverterFactories: []confmap.ConverterFactory{expandconverter.NewFactory()},
				                                               ^
Error: command_test.go:91:52: SA1019: expandconverter.NewFactory is deprecated: [v0.102.0] Expanding $ENV is no longer supported. To expand ${} using env vars use DefaultScheme="env" or the otelcol.useStableExpansionRules feature gate. (staticcheck)

@TylerHelmuth
Copy link
Member Author

I believe the actual deprecation depends on #10281

codeboten added a commit that referenced this pull request Jun 4, 2024
#### Description

Allows configuring `DefaultScheme` via the builder config.

#### Link to tracking issue
Related to
#10259
Related to
#10290

#### Testing
Local testing and unit tests

---------

Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
Copy link
Member

@mx-psi mx-psi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be good to add some config provider tests that show what the change in behavior is before and after enabling the feature gate

.chloggen/confmap-add-expand-featuregate-2.yaml Outdated Show resolved Hide resolved
.chloggen/confmap-add-expand-featuregate.yaml Outdated Show resolved Hide resolved
@TylerHelmuth
Copy link
Member Author

This PR is currently under the assumption that we'll stop providing default providers and converters in NewCommand. If we decide to keep doing that, I'll open a new PR that keeps the feature gate in otelcol and does the same logic as the builder when setting defaults.

@TylerHelmuth
Copy link
Member Author

Created #10361 as an alternative

@TylerHelmuth TylerHelmuth requested a review from mx-psi June 10, 2024 20:12
.chloggen/confmap-add-expand-featuregate.yaml Outdated Show resolved Hide resolved
cmd/builder/internal/builder/templates/main.go.tmpl Outdated Show resolved Hide resolved
@TylerHelmuth
Copy link
Member Author

So it turns out featuregates don't work in main.go because it happens before flags are read in. @codeboten and I found this while writing an integration test.

So I need to rework this PR to do the manipulation inside otelcol like I originally had it 😢

@TylerHelmuth
Copy link
Member Author

This solution doesn't work, need #10391 instead

@TylerHelmuth TylerHelmuth deleted the confmap-add-expand-featuregate branch June 12, 2024 01:27
mx-psi pushed a commit that referenced this pull request Jun 14, 2024
#### Description
This PR adds a feature gate that will handle transitioning users away
from expandconverter, specifically expanding `$VAR` syntax.

The wholistic strategy is:
1. create a new feature gate, `confmap.unifyEnvVarExpansion`, that will
be the single feature gate to manage unifying collector configuraiton
resolution.
2. Update expandconverter to return an error if the feature gate is
enabled and it is about to expand `$VAR` syntax.
3. Update `otelcol.NewCommand` to set a `DefaultScheme="env"` when the
feature gate is enabled and no `DefaultScheme` is set, this handles
`${VAR}` syntax.
  4. Separately, deprecate `expandconverter`.
  5. Follow a normal feature gate cycle.
6. Removed the `confmap.unifyEnvVarExpansion` feature gates and
`expandconverter` at the same time

Supersedes
#10259

#### Link to tracking issue
Related to
#10161
Related to
#8215
Related to
#7111

#### Testing
Unit tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants