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

New component: configconverter to help migrate users between components #30654

Closed
2 tasks
atoulme opened this issue Jan 17, 2024 · 10 comments
Closed
2 tasks

New component: configconverter to help migrate users between components #30654

atoulme opened this issue Jan 17, 2024 · 10 comments
Labels
Sponsor Needed New component seeking sponsor

Comments

@atoulme
Copy link
Contributor

atoulme commented Jan 17, 2024

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

@atoulme atoulme added Sponsor Needed New component seeking sponsor needs triage New item requiring triage labels Jan 17, 2024
@mx-psi
Copy link
Member

mx-psi commented Jan 24, 2024

@songy23
Copy link
Member

songy23 commented Jan 24, 2024

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
Copy link
Contributor Author

atoulme commented Jan 24, 2024

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
Copy link
Member

songy23 commented Jan 24, 2024

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
Copy link
Contributor Author

atoulme commented Jan 24, 2024

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
Copy link
Member

songy23 commented Jan 24, 2024

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
Copy link
Contributor Author

atoulme commented Jan 24, 2024

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
Copy link
Member

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

@atoulme
Copy link
Contributor Author

atoulme commented Feb 28, 2024

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

Copy link
Contributor

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.

@github-actions github-actions bot added the Stale label Apr 29, 2024
@mx-psi mx-psi removed the Stale label Apr 29, 2024
@atoulme atoulme closed this as completed May 30, 2024
@atoulme atoulme closed this as not planned Won't fix, can't repro, duplicate, stale May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Sponsor Needed New component seeking sponsor
Projects
None yet
Development

No branches or pull requests

4 participants