-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[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
[otelcol] Make the ConfigProvider
interface a struct
#12297
Conversation
@@ -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) { |
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.
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.
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 will ask a different question. Does this need to be public at all?
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.
My initial preference was to make everything in this file internal. However, if we do that, I see two issues:
- There's no meaningful replacement for distro authors without forking this code, and I see quite a few usages. For example:
- https://github.com/observIQ/bindplane-otel-collector/blob/69053af3a2a2cbc23b994faf40865aaabff0b1c5/receiver/pluginreceiver/supplied_plugins_test.go#L109
- https://github.com/grafana/tempo/blob/60245c6c2e84d798a01d5af27b7325bdf16c1593/modules/distributor/receiver/shim.go#L214
- https://github.com/grafana/alloy/blob/60f43c5ad23f11e01c7e95829a4bd71baec29486/internal/converter/internal/otelcolconvert/otelcolconvert.go#L87
- https://github.com/SigNoz/signoz-otel-collector/blob/f10f88640de8cf52ce888b8c229949b2f111b9c2/pkg/collectorsimulator/collectorsimulator.go#L114
- https://github.com/xobserve/xobserve/blob/35c2745b913bae4a78dfa7ba212e24150190fc3b/otel-collector/pkg/config/factory.go#L39
- 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.
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
Description
The
ConfigProvider
interface is not very useful since it isn't used byotelcol.Collector
anymore since we moved to creating it throughConfigProviderSettings
insideotelcol.Collector
. Therefore, we should just makeconfigProvider
the concrete implementation and remove the interface. We could consider entirely removingConfigProvider
from the API, but it is used by some downstream distributions, and there is no other way to marshal YAML intootelcol.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.