Skip to content

[otelcol] Make the ConfigProvider interface a struct #12297

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

Merged

Conversation

evan-bradley
Copy link
Contributor

@evan-bradley evan-bradley commented Feb 5, 2025

Description

The ConfigProvider interface is not very useful since it isn't used by otelcol.Collector anymore since we moved to creating it through ConfigProviderSettings inside otelcol.Collector. Therefore, we should just make configProvider the concrete implementation and remove the interface. We could consider entirely removing ConfigProvider from the API, but it is used by some downstream distributions, and there is no other way to marshal YAML into otelcol.Config, so we would need to make additional changes to provide an adequate replacement.

We could also follow our deprecation process for this change, but in my opinion that will only cause more churn for downstream consumers since they will need to update their code multiple times throughout the process instead of just once.

@evan-bradley evan-bradley requested a review from a team as a code owner February 5, 2025 16:23
@@ -62,18 +36,21 @@ type ConfigProviderSettings struct {
// - Then applies all the confmap.Converter in the given order.
//
// * Then unmarshalls the confmap.Conf into the service Config.
func NewConfigProvider(set ConfigProviderSettings) (ConfigProvider, error) {
func NewConfigProvider(set ConfigProviderSettings) (*ConfigProvider, error) {
Copy link
Contributor Author

@evan-bradley evan-bradley Feb 5, 2025

Choose a reason for hiding this comment

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

This is probably the biggest breaking change in this PR. If we return ConfigProvider instead of *ConfigProvider, it's likely that the change would go unnoticed by downstream users of this function. However, we typically return pointers for structs like this one, so not returning a point here would break that pattern.

The only field in this struct is a pointer, so from an efficiency standpoint I don't think it matters much whether this is a pointer or not.

Copy link
Member

Choose a reason for hiding this comment

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

I will ask a different question. Does this need to be public at all?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My initial preference was to make everything in this file internal. However, if we do that, I see two issues:

  1. There's no meaningful replacement for distro authors without forking this code, and I see quite a few usages. For example:
  1. There would be no way to unmarshal an otelcol.Config struct from the Collector's YAML, since all of the unmarshaling facilities are private. We should solve this separately.

My preference would be to make this smaller change for now, and reevaluate unexporting this at least after (2) is resolved.

Copy link

codecov bot commented Feb 5, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.35%. Comparing base (fb06c99) to head (65c665c).
Report is 24 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main   #12297   +/-   ##
=======================================
  Coverage   91.35%   91.35%           
=======================================
  Files         467      467           
  Lines       25761    25761           
=======================================
  Hits        23533    23533           
  Misses       1810     1810           
  Partials      418      418           

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

@codeboten codeboten added this pull request to the merge queue Feb 10, 2025
Merged via the queue into open-telemetry:main with commit e86edee Feb 10, 2025
54 checks passed
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.

4 participants