feat(chore): declarative configuration for trace_provider

[xuan-cao-swi]

Description

This PR introduces an initial declarative configuration implementation for OpenTelemetry Ruby under otelconfig, intentionally scoped to tracing only.

I followed the Go otelconfig convention for config structure and behavior where it maps well to Ruby.

Minimalist approach: no hard dependency on optional components, which optional propagators and resource detectors are resolved only if the corresponding gem has been required by the user. If an optional component is not available, configuration continues safely with warnings instead of failing startup.

Scope in this PR

• Trace configuration only:
  • tracer provider setup
  • samplers
  • span processors
  • trace exporters
  • span limits
• Declarative resource and propagation wiring needed for trace setup
• Instrumentation mapping/installation flow for declarative config
• Tests and example configuration for the implemented behavior

Try /example

Updated (2026-06-13):

• The in-memory struct of opentelemetry configuration now is based on https://github.com/open-telemetry/opentelemetry-configuration/tree/v1.0.0-rc.3/schema. bundle exec rake generate:constants will auto-generate the struct file.
• configuration will return RubySDK struct that contain providers, which user need to set the global provider point to the providers

  sdk = OpenTelemetry::OtelConfig.configure
  OpenTelemetry.tracer_provider = sdk.tracer_provider

[thompson-tomo]

One other thing, how are we ensuring the loading of the the env variables are disabled when covered by declarative config?

Will the current approach support dynamic reloading of the config which is also a part of the spec?

[mwear]

I like the approach overall. I have a few comments based on a first pass through.

[mwear]

This only returns an SDK on the happy path. Other paths vary in what they return. We should define what happens on these other paths? Do we want to always return an SDK backed by no-op components or something else?

[xuan-cao-swi]

Now it will return noop sdk (e.g. noop provider and propagator) if parsing failed

[mwear]

Sorry, I have been slow to review the declarative config PRs. I notice we also have #21960 proposing a slightly different shape for declarative config. We should discuss further in #2127 and see if we can align on an approach.