OpenTelemetry reported "unknown variable" before first Ingress #11044
Labels
kind/support
Categorizes issue or PR as a support question.
lifecycle/frozen
Indicates that an issue or PR should not be auto-closed due to staleness.
needs-priority
needs-triage
Indicates an issue or PR lacks a `triage/foo` label and requires one.
What happened:
While doing some Disaster Recovery testing, we re-deployed
ingress-nginx
with the followinghttp-snippet
to log trace IDs (pulled from opentracing-contrib/nginx-opentracing#33):When it spins up, until the first Ingress is created, the
opentelemetry_
variables are all unknown, resulting in the following error:What you expected to happen:
I would prefer that setting the following makes the
opentelemetry_
variable available from the start, instead of waiting for the first Ingress:Alternatively, I've tried figuring out a workaround to just ignore the variable if unavailable using
map
and could not find anything workable, and know that's likely outside the scope of this issue.NGINX Ingress controller version (exec into the pod and run nginx-ingress-controller --version.):
Kubernetes version (use
kubectl version
):(This is from testing locally with minikube)
Environment:
uname -a
): N/Ahelm template
and then applied locally or pushed to a control repo and consumed by ArgoPlease mention how/where was the cluster created like kubeadm/kops/minikube/kind etc.
kubectl version
kubectl get nodes -o wide
Rendered using
helm template
either locally for testing or via Gitlab CI, and then pushed to a controller repo and consumed by Argo (or applied locally to minikube for testing).kubectl describe ingressclasses
kubectl -n <ingresscontrollernamespace> get all -A -o wide
kubectl -n <ingresscontrollernamespace> describe po <ingresscontrollerpodname>
kubectl -n <ingresscontrollernamespace> describe svc <ingresscontrollerservicename>
kubectl -n <appnamespace> get all,ing -o wide
kubectl -n <appnamespace> describe ing <ingressname>
If applicable, then, your complete and exact curl/grpcurl command (redacted if required) and the reponse to the curl/grpcurl command with the -v flag
Others:
kubectl describe ...
of any custom configmap(s) created and in useHow to reproduce this issue:
Install minikube locally. Set up the following Helm chart:
And set the following in
values.yaml
:Render it went
helm template
and thenkube apply -f
. When the pod comes up,kubectl logs
to see the above errors.Anything else we need to know:
Not sure if the request is nonsensical, so open to a work-around to just... ignore the issue until an Ingress is created, but it's been a bit of an annoyance during testing.
The text was updated successfully, but these errors were encountered: