Mikołaj Świątek

I'm a bit stuck on the shortcut mechanism for connecting OpenTelemetryCollector and TargetAllocator CRs. The approach from https://github.com/open-telemetry/opentelemetry-operator/issues/2422#issuecomment-1862635932 works, but I don't like its ergonomics. The requirements for this connection...

Discussed the above during the SIG meeting. The conclusions were: * Manage the connection via a label on the OpenTelemetryCollector CR. It is then easy for the Target Allocator reconciliation...

I realized that the above results in some awkwardness with the embedded TargetAllocator, as we'd need to add a label to the Collector CR while reconciling it, despite the Collector...

Would it also help to make the jobs conditional on the required secrets existing? I'm ok with this change overall, but I don't like duplicating the tag extraction logic in...

@rashmichandrashekar yeah, in my opinion we should do something very similar to what the target allocator does and just serialize the configs to yaml, and hash the output. They should...

The exporter is not using that directly, but rather inheriting it from our extension, which it uses as a dependency. https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/33403 will resolve this issue.

Unpinning this, as the change was reverted upstream in https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/23229. I'm going to keep it open for now.

Closing, as this is not relevant anymore.

This is a limitation of Sumo http sources. Even though Sumo can actually render the values, it can't ingest them as header values if they contain commas. The same limitation...

Since this only happens for new otel Pods, I have a suspicion that it's because the k8sprocessor processed data without first having populated its Pod cache completely. As I suggested...