Support for TLS on the OpenTelemetry Jaeger Exporter

[ppatierno]

When using the OpenTelemetry support for tracing, the default exporter is the Jaeger one.
It is configured by the operator automatically when the tracing type is set to opentelemetry.
The exporter is configured via some OTEL_ prefixed env vars which are used by the OpenTelemetry SDK auto-configure extension in order to configure the exporter accordingly.
Anyway, it seems that it's not possible to enable TLS on the Jaeger Exporter client if it's needed when the Jaeger backend has TLS enabled on the gRPC port.
The same apply if the user decide to use the Zipkin exporter.
Instead, if the OTLP exporter is used (which is the builtin provided by OpenTelemetry project), there are different env vars to be set for providing the TLS certificate and key.
It sounds to be a limit of the OpenTelemetry SDK auto-configure extension, because the Jaeger Exporter supports TLS by itself is used from the code.
I opened an issue in the OpenTelemetry community here open-telemetry/opentelemetry-java#4917 and we should come back to this if/when such a support will be added, in order to allow the operator to mount volumes (from ConfigMap or Secret) for getting TLS certificate and key.

[ppatierno]

From the OTel folks answer on the above issue, it's pretty clear that:

• the Jeager exporter will never get TLS client support
• the Jeager exporter is going to be deprecated at some point (more info on this blog post as well)
• they are pushing to use OTLP exporter

For this reason I would close this issue and opening a new one related to the OTLP exporter migration, mentioning the Jaeger exporter deprecation and removal in future Strimzi release as well.

@strimzi/maintainers wdyt?

[im-konge]

I would go with a path of closing this issue and creating new one, which will focus on OTLP exporter migration. Thank you for investigating @ppatierno :)

[ppatierno]

Because Jaeger exporter is not supported anymore in our OpenTelemetry deployment but we have the OTLP one in place, going to close this to be replaced by #9170