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

Collector fails to expand env vars when the value is an IPv6 address with trailing double colon #10605

Closed
congiv opened this issue Jul 12, 2024 · 2 comments · Fixed by #10618
Closed
Labels
area:confmap bug Something isn't working

Comments

@congiv
Copy link

congiv commented Jul 12, 2024

Describe the bug

On startup, the collector fails to expand env vars when the value is an IPv6 address with trailing double colon. It treats the value as a map instead of a string.

Steps to reproduce

In my environment, I see this when the collector Pod's IPv6 address has a trailing double colon. Given MY_POD_IP=1111:1111:1111:1111:1111::, this fails to expand:

config:
  receivers:
    zipkin:
      endpoint: '[${env:MY_POD_IP}]:9411'

If you don't have an environment where you can get a IPv6 Pod, you can also reproduce like so:

extraEnvs:
- name: MY_MOCK_IP
  value: '1111:1111:1111:1111:1111::'
# ...
config:
  receivers:
    zipkin:
      endpoint: '[${env:MY_MOCK_IP}]:9411'

What did you expect to see?

The collector start successfully with its config expanded, regardless of whether the Pod's IPv6 address has a leading or trailing double colon.

What did you see instead?

Error: failed to resolve config: cannot resolve the configuration: expanding ${env:MY_POD_IP}: expected convertable to string value type, got map["1111:1111:1111:1111:1111:":<nil>](map[string]interface {})
2024/07/12 17:54:20 collector server run finished with error: Error: failed to resolve config: cannot resolve the configuration: expanding ${env:MY_POD_IP}: expected convertable to string value type, got map["1111:1111:1111:1111:1111:":<nil>](map[string]interface {})

What version did you use?

0.104.0

What config did you use?

config:
  receivers:
    zipkin:
      endpoint: '[${env:MY_POD_IP}]:9411'

Environment

Kubernetes Version: 1.28.11-eks-db838b0
Helm Chart Version: 0.97.1
Docker Image Version: otel/opentelemetry-collector-contrib:0.104.0

Additional context

Looks like this may have been partially resolved with #10343

@congiv congiv added the bug Something isn't working label Jul 12, 2024
@evan-bradley
Copy link
Contributor

Thanks for the detailed report @congiv. This is happening due to the fact that :: is the confmap delimiter for config paths (e.g. dist::version indicates the version key under the dist map). I'll let others chime in here if they know a better solution, but if you have the ability to manipulate the environment variable in any way before it reaches the Collector, you can try to wrap it in a string.

I was able to reproduce your issue locally and setting something like MY_POD_IP="'1111:1111:1111:1111:1111::'", where the value is seen as quoted by the YAML parser, allowed the Collector to recognize the IP as a string.

@evan-bradley
Copy link
Contributor

This may also be solved by #10603.

mx-psi added a commit that referenced this issue Jul 16, 2024
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description

<!-- Issue number if applicable -->

Allow using strings parseable in YAML as `map[string]any` in inline
position

#### Link to tracking issue

Relates to #10605 (does not fix it since it's not in inline position)
@mx-psi mx-psi closed this as completed in 0001db2 Jul 25, 2024
RonFed added a commit to odigos-io/odigos that referenced this issue Aug 8, 2024
Relevant breaking changes in the collector that are addressed in this PR
(from the [contribe
releases](https://github.com/open-telemetry/opentelemetry-collector-contrib/releases)
and [collector
release](https://github.com/open-telemetry/opentelemetry-collector/releases).


> The otlpreceiver now uses localhost by default instead of 0.0.0.0.
This may break the receiver in containerized environments like
Kubernetes. If you depend on 0.0.0.0 disable the
component.UseLocalHostAsDefaultHost feature gate or explicitly set the
endpoint to 0.0.0.0

> confmap: When passing configuration for a string field using any
provider, use the verbatim string representation as the value.
(open-telemetry/opentelemetry-collector#10605,
open-telemetry/opentelemetry-collector#10405)
This matches the behavior of ${ENV} syntax prior to the promotion of the
confmap.unifyEnvVarExpansion feature gate
to beta. It changes the behavior of the ${env:ENV} syntax with escaped
strings
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:confmap bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants