New component: configconverter to help migrate users between components

[atoulme]

The purpose and use-cases of the new component

This component is a configuration converter that is currently hosted by Splunk for its own distribution and is used to work through migrations of component configurations.

This converter sits on the configuration initial load and runs through the confmap mapstructure object and makes modifications to take care of configuration breaking changes.

An example exists here: https://github.com/signalfx/splunk-otel-collector/blob/main/internal/configconverter/loglevel_to_verbosity.go

This type of change allows moving between component types, such as spanmetricsprocessor to spanmetricsconnector. The configuration is migrated over to the new component, along with a warning and a prompt for the user to integrate the changes moving forward.

Incorporating this type of feature in the collector will allow us to safely deprecate and dispose of components that are deprecated such as spanmetricsprocessor, servicegraphprocessor, and deal with breaking changes in configuration by explicitly helping customers through conversion.

Example configuration for the component

An example of dealing with log_level to verbosity is available here: https://github.com/signalfx/splunk-otel-collector/blob/main/internal/configconverter/loglevel_to_verbosity.go

Telemetry data types supported

all

Is this a vendor-specific component?

• This is a vendor-specific component
• If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.

Code Owner(s)

No response

Sponsor (optional)

No response

Additional context

No response

[mx-psi]

Duplicate of open-telemetry/opentelemetry-collector/issues/7631 ? cc @songy23

[songy23]

Yes I think open-telemetry/opentelemetry-collector#7631 serves pretty similar purpose. In the given example https://github.com/signalfx/splunk-otel-collector/blob/main/internal/configconverter/loglevel_to_verbosity.go, the subcommand works like

# assume examples/local/otel-config.yaml has logging exporter with loglevel
$ ./otelcorecol migrate --config=file:examples/local/otel-config.yaml
---
...
exporter:
  logging:
    verbosity: detailed
...
---

@atoulme Does the above meet your requirements or do you still think we need a separate configconverter component?

[atoulme]

Our configconverter module runs as part of config initialization and translates the confmap entries over, so it doesn't change files. It emits warnings when it finds conversions to make, with a snippet showing the changes to make, so folks can apply them themselves.

[songy23]

so it doesn't change files. It emits warnings when it finds conversions to make, with a snippet showing the changes to make, so folks can apply them themselves.

That's actually the same as the subcommand in open-telemetry/opentelemetry-collector#7631 - it does not modify the input source either (because in many cases it cannot modify the input), instead it will just print out the new configs if any updates are made. Then the users are free to copy and apply those changes.

[atoulme]

Sorry, I think you're pointing at an issue. Are you saying we have code towards this in the repo already? Or maybe a PR? Please link and we can look at contributing and adopting the approach.

[songy23]

The subcommand is WIP, so it isn't yet available in core. If the subcommand approach makes sense to you, we can probably work together.

Just want to avoid duplicated work since it sounds like the configconverter and the migration subcommand are targeting the same thing.

[atoulme]

Yes, definitely interested to help and contribute. We can work on this together. Please tag me if/when you have a PR open and we can review.

[crobert-1]

@atoulme Do we still want this issue to be open, or should this be done in the core issue referenced above?

[atoulme]

I probably would leave things as is for now as this is a bit difficult to navigate.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.