You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(config): honour OTEL_PYTHON_* extensions when OTEL_CONFIG_FILE is set #5352
When `OTEL_CONFIG_FILE` is set, `_OTelSDKConfigurator.configure` returns early after calling `configure_sdk(load_config_file(path))`, which means every `OTEL_PYTHON*` implementation extension (e.g. `OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED`, `OTEL_PYTHON_TRACER_CONFIGURATOR`) is silently bypassed. These are Python-specific extensions outside the OTel configuration spec, so they have no equivalent in the schema, and ignoring them when a file is present is documented as intentional in #5335 (the current-behaviour decision).
This issue tracks the future-state work to actually honour those extensions alongside the file.
Why
Users migrating from an env-var config to a YAML file expect their existing `OTEL_PYTHON_*` knobs to keep working. Today they silently stop, which is a likely "why doesn't my app behave the same?" support footgun. The spec says the file is authoritative for spec-defined variables only; nothing in the spec prevents an implementation from continuing to honour its own extensions.
Proposed shape
Two layers to design:
Behaviour layer: when `OTEL_CONFIG_FILE` is set, after `configure_sdk` returns, run a small `apply_python_extensions()` step that reads each `OTEL_PYTHON*` env var and applies it on top of the global SDK objects that `configure_sdk` produced. Specifically:
`OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED` → set up the logging handler.
`OTEL_PYTHON_{TRACER,METER,LOGGER}_CONFIGURATOR` → load and apply the named configurator to the corresponding global provider.
`OTEL_PYTHON_ID_GENERATOR` → maybe; once #5334 lands the schema covers this anyway and the file should win.
Schema-extension layer: if we want any of the above to be expressible in the YAML itself, that's a schema extension and should go through the config spec.
Out of scope (for this issue)
The decision to bypass currently (that is documented under #5335).
Anything related to spec-defined `OTEL_*` variables: the spec is clear that the file wins.
Activity
GauravR31 commentedon Sep 26, 2026
@MikeGoldsmith I've got a PR up for the behavior layer changes at #5699, happy to take on any feedback. Thank you!