Request confmap.Converter as component able to be built/included with OCB

[jackgopack4]

Is your feature request related to a problem? Please describe.
Would like to be able to include a confmap.Converter component as a go module in an ocb manifest/builder-config.yaml

Describe the solution you'd like
another option in the ocb components template for converters and subsequent yaml configuration options in the config.yaml file

Describe alternatives you've considered
currently we are using a non-ocb build process to build an OTel-compatible collector to make it easier to automatically apply required vendor-specific settings/components to the collector; this cannot be replicated by a customer using ocb.

Additional info
In order to use this feature, users should be aware of the following items:

• Converters are applied prior to component startup
• Converters are applied in order (the build manifest must list them in order to be parsed and applied correctly).
  • Can anyone else help confirm that the manifest will be parsed by koanf in order or if that's not guaranteed?
  • If not, we may need to add an order key/value pair in the config.yaml to be used with each converter added to ensure that they get applied in the proper order
• Only one converter is currently published and it is deprecated (expandconverter)

Example configuration

dist:
  module: go.opentelemetry.io/collector/cmd/otelcorecol
  name: otelcorecol
  description: Local OpenTelemetry Collector binary, testing only.
  version: 0.112.0-dev
  otelcol_version: 0.112.0

receivers:
  - gomod: go.opentelemetry.io/collector/receiver/nopreceiver v0.112.0
  - gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.112.0
exporters:
  - gomod: go.opentelemetry.io/collector/exporter/debugexporter v0.112.0
  - gomod: go.opentelemetry.io/collector/exporter/nopexporter v0.112.0
  - gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.112.0
  - gomod: go.opentelemetry.io/collector/exporter/otlphttpexporter v0.112.0
extensions:
  - gomod: go.opentelemetry.io/collector/extension/memorylimiterextension v0.112.0
  - gomod: go.opentelemetry.io/collector/extension/zpagesextension v0.112.0
processors:
  - gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.112.0
  - gomod: go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.112.0
connectors:
  - gomod: go.opentelemetry.io/collector/connector/forwardconnector v0.112.0

providers:
  - gomod: go.opentelemetry.io/collector/confmap/provider/envprovider v1.18.0
  - gomod: go.opentelemetry.io/collector/confmap/provider/fileprovider v1.18.0
  - gomod: go.opentelemetry.io/collector/confmap/provider/httpprovider v1.18.0
  - gomod: go.opentelemetry.io/collector/confmap/provider/httpsprovider v1.18.0
  - gomod: go.opentelemetry.io/collector/confmap/provider/yamlprovider v1.18.0

converters:
  - gomod: go.opentelemetry.io/collector/confmap/converter/expandconverter v0.112.0

[evan-bradley]

@mx-psi When we discussed this while adding confmap.Providers to the builder, we said we wanted to forgo Converters for the time-being since there aren't any non-deprecated upstream Converters and it's possible we'd like to deprecate the interface in the future. Is the expectation now that confmap will go 1.0 with the Converter interface and that's why we'd like to add support in the builder, or are there external Converter use cases this could help with?

[mx-psi]

Is the expectation now that confmap will go 1.0 with the Converter interface and that's why we'd like to add support in the builder

I'd say so, yes, since it's part of confmap 1.0 we should support converters in general. Splunk makes heavy use of converters, which is the main reason we kept this/

are there external Converter use cases this could help with

In this particular case, I think Datadog wants to use this to be able to build this. It would also be nice to support building Splunk's distro with ocb IMO, we could gather useful feedback from them if they end up using it.

[evan-bradley]

That all makes sense to me, thanks for the details.