Skip to content

Keep distro resource attributes under declarative configuration - #10

Draft
mmanciop wants to merge 1 commit into
mainfrom
fix/declarative-config-resource-attributes
Draft

Keep distro resource attributes under declarative configuration#10
mmanciop wants to merge 1 commit into
mainfrom
fix/declarative-config-resource-attributes

Conversation

@mmanciop

@mmanciop mmanciop commented Jul 21, 2026

Copy link
Copy Markdown
Member

Fixes #6

Problem

When OTEL_CONFIG_FILE is set, the declarative resource builder ignores OTEL_RESOURCE_ATTRIBUTES and OTEL_SERVICE_NAME, so the attributes the distro injects into the environment — telemetry.distro.name/telemetry.distro.version, k8s.pod.uid, and the fallback service.name — silently disappeared from the exported resource. The detectors from #11 are not enough on their own: declarative configuration only runs detectors listed in the config file, so users would have to edit their YAML to keep the attributes.

Changes

Dash0Configurator now handles OTEL_CONFIG_FILE itself: it loads the config file, adds the missing dash0_* detectors to the parsed configuration, and hands it to configure_sdk — the attributes survive without any config-file changes.

  • Detected attributes merge below explicit config attributes, so values declared in the file still win, and detectors already listed there are not added twice.
  • The declarative machinery is resolved from both layouts: the file-configuration extra inside SDK 1.43 and the standalone opentelemetry-configuration package of SDK 1.44+. When neither is importable, the configurator falls back to the base class, which reports its usual error.
  • opentelemetry-sdk[file-configuration] is added as a dev dependency so the unit tests exercise the declarative path; whether it becomes a runtime dependency is tracked in Declarative configuration (OTEL_CONFIG_FILE) fails out of the box: declarative-config dependencies are not installed #5.

Note: on the pinned SDK 1.43 the upstream loader rejects the spec's resource.detection/development config-file key (fixed upstream in 1.44), so the automatic injection is currently the only way resource detectors run under declarative configuration.

@mmanciop
mmanciop force-pushed the fix/declarative-config-resource-attributes branch from f83d2e1 to 6fc4bfd Compare July 21, 2026 16:51
@mmanciop
mmanciop changed the base branch from tighten-dependency-pins to main July 21, 2026 16:51
@mmanciop
mmanciop marked this pull request as draft July 21, 2026 16:54
@mmanciop
mmanciop force-pushed the fix/declarative-config-resource-attributes branch from 6fc4bfd to d12519d Compare July 21, 2026 17:06
@mmanciop
mmanciop changed the base branch from main to resource-detector-entry-points July 21, 2026 17:06
When OTEL_CONFIG_FILE is set, the declarative resource builder ignores
OTEL_RESOURCE_ATTRIBUTES and OTEL_SERVICE_NAME, so the attributes the
distro injects into the environment (telemetry.distro.*, k8s.pod.uid,
and the fallback service.name) silently disappeared. Registering the
dash0_* resource detectors (#11) is not enough on its own:
declarative configuration only runs detectors listed in the config
file, so users would have to edit their YAML to keep the attributes.

Dash0Configurator now handles OTEL_CONFIG_FILE itself: it loads the
config file, adds the missing dash0_* detectors to the parsed
configuration, and hands it to configure_sdk, so the attributes survive
without any config file changes. Detected attributes merge below
explicit config attributes, so values declared in the file still win,
and detectors already listed there are not added twice. The declarative
machinery is resolved from both layouts, the file-configuration extra
shipped inside SDK 1.43 and the standalone opentelemetry-configuration
package of SDK 1.44+, and when neither is importable the configurator
falls back to the base class, which reports its usual error.

The SDK's file-configuration extra becomes a dev dependency so the unit
tests exercise the declarative path; whether the declarative machinery
becomes a runtime dependency is tracked in #5. Note that on the pinned
SDK 1.43 the upstream loader rejects the spec's
resource.detection/development config-file key (fixed upstream in
1.44), so the automatic injection is currently the only way resource
detectors run under declarative configuration.

Fixes #6
@mmanciop
mmanciop force-pushed the fix/declarative-config-resource-attributes branch from d12519d to 2d56ef3 Compare July 22, 2026 07:24
@mmanciop
mmanciop changed the base branch from resource-detector-entry-points to main July 22, 2026 07:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Distro resource attributes (telemetry.distro.*, k8s.pod.uid, fallback service name) are dropped under declarative configuration

1 participant