Enable confmap expand feature

[bogdandrutu]

Examples of usages

Retrieving token from zookeeper (scheme not yet defined)

exporters:
  signalfx:
    # this will read the access_token value from "zk" config provider.
    access_token: ${zk:zk1,zk2,zk2/path/to/data}

Retrieving an entire exporter config from a file

exporters:
  # this will read the entire config for the otlp/file exporter from the given file
  otlp/file_config: ${file:path/to/config/file/for/the/exporter.yaml}

Expanding env vars

exporters:
  otlp:
    endpoint: ${env:MY_ENV}

The old way of expanding env vars (without a scheme) is still supported (for at least few versions) but discouraged at this point and should be replaced by the new usage pattern.

[codecov]

Codecov Report

Base: 92.30% // Head: 92.31% // Increases project coverage by +0.01% 🎉

Coverage data is based on head (ace188f) compared to base (ff73e49).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6276      +/-   ##
==========================================
+ Coverage   92.30%   92.31%   +0.01%     
==========================================
  Files         219      219              
  Lines       13466    13473       +7     
==========================================
+ Hits        12430    12438       +8     
+ Misses        806      805       -1     
  Partials      230      230              

Impacted Files	Coverage Δ
confmap/resolver.go	98.13% <100.00%> (+0.73%)	⬆️
pdata/pmetric/metrics.go	100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[dmitryax]

Should we enable it through a feature gate at the beginning? I believe it might introduce some unexpected outcomes for distros that do it using another approach...

[bogdandrutu]

Should we enable it through a feature gate at the beginning? I believe it might introduce some unexpected outcomes for distros that do it using another approach...

No, because that has a different syntax which does not match this one, so the mechanism will not trigger.

The reason a featureflag is not required is because is a new syntax, and if users are using this new syntax is clear that they want this feature, otherwise this feature is not triggered.

[bogdandrutu]

@dmitryax convinced me that this may overlap with splunk's distros feature, so protect this by a feature gate for the moment.

[Aneurysm9]

The old way of expanding env vars (without a scheme) is still supported (for at least few versions)

This is a significant feature of the configuration system used by many users in many ways. We need to be very careful about this transition and ensure that it is seamless as possible. I don't think we can simply say it will go away in a couple of releases.

[bogdandrutu]

@Aneurysm9 when that moment comes, happy to hear opinions, for the moment let's aim for that (be positive).

[Aneurysm9]

All I'm saying is that if we want to make this change the time to plan for transition is now, not when we're ready to disable functionality that users have relied on up to this point.