What
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.
Related
What
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:
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)
Related