Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OTEL_RESOURCE_ATTRIBUTES not loaded from configmap #3419

Closed
dariusj1 opened this issue Nov 4, 2024 · 1 comment
Closed

OTEL_RESOURCE_ATTRIBUTES not loaded from configmap #3419

dariusj1 opened this issue Nov 4, 2024 · 1 comment
Labels
bug Something isn't working needs triage

Comments

@dariusj1
Copy link

dariusj1 commented Nov 4, 2024

Component(s)

auto-instrumentation

What happened?

Description

According to https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/agent-features.md

Environment variable configuration as per spec

It indeed works, but only if I specify those envs in the .spec.container[*].env block as inline environments.

HOWEVER, it doesn't seem to be working if I configure my pod manifest to load environments from a configmap. In that case, the operator sets the env in pod manifest level completely ignoring the envs in configmap.

This is the case with environment variables that operator sets itself, e.g. OTEL_RESOURCE_ATTRIBUTES.

Steps to Reproduce

Expected Result

I'd expect the operator to acocunt for env vars loaded from external resources too, i.e. secrets and configmaps

Actual Result

operator ignores OTEL_RESOURCE_ATTRIBUTES defined in configmap. But it does work as expected if I export this env directly in pod's manifest.

Kubernetes Version

v1.30.4-eks-a737599

Operator version

0.72.0

Collector version

N/A

Environment information

No response

Log output

No response

Additional context

No response

@dariusj1 dariusj1 added bug Something isn't working needs triage labels Nov 4, 2024
@jaronoff97
Copy link
Contributor

this is a duplicate of what is discussed in this issue and i am going to close this in favor of that one. TL;DR: this would require us to get permissions to peak into arbitrary configmaps (and secrets) which is something we're wary of doing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs triage
Projects
None yet
Development

No branches or pull requests

2 participants