Open paebersold-tyro opened 1 month ago
One way that I got around it was to deploy the OpenTelemetryCollector without the istio podAnnotations and to let the target allocator deploy and then add the istio podAnnotations on the OpenTelemetryCollector. I could see that it updated the otel pod with the istio proxy but did not try to redeploy the target allocator. Hope it helps.
Component(s)
target allocator
What happened?
Description
Hello, this is half bug/half feature request.
We are using the otel-operator as a daemonset with the target allocator enabled (via the operator helm chart). We are also using istio (sidecar being auto injected). For the setting up of prometheus scraping endpoints inside the istio mesh we are following the istio guidelines (https://istio.io/latest/docs/ops/integrations/prometheus/#option-2-customized-scraping-configurations) around this. In short we need to add a podannotaton and a volume and volumemount setup on the pod (ie the collector) doing the scraping.
I can do this via the OpenTelemetryCollector setup with 'podannotations/volumes/volumenmounts'. However only the podannotations are passed onto the target allocator deployment. Not the volumes/volumemounts. So the target allocator fails to start as it tries to (via the annotation) mount a volume that doesn't exist.
Is there a way around this within the OpenTelemetryCollector config?
Steps to Reproduce
Setup OpenTelemetryCollector object with istio suggested setup
Expected Result
Target allocator gets the same resources as the collector pods
Actual Result
It doesn't so is unable to start. See log below.
Kubernetes Version
1.30
Operator version
0.102.0
Collector version
0.103.0
Environment information
Helm chart - https://open-telemetry.github.io/opentelemetry-helm-charts / opentelemetry-operator / 0.62.0 Target allocator - 0.107.0
Log output
Additional context
OpenTelemetryCollector config
Generated target allocator deployment