[Feature]: Support Jaeger-v2

[yurishkuro]

Requirement

Once Jaeger-v2 (jaegertracing/jaeger#4843) reaches production readiness and feature parity, we may want to support it in the helm chart.

Problem

Jaeger-v2 is based on OpenTelemetry Collector and uses completely different configuration mechanism:

• all configuration is done via config files, not CLI flags or env vars (although some env vars are supported by telemetry SDKs)
• it is a single binary that can be deployed into different roles (collector, query, etc.) also based on configuration, but in this case with structural config changes, not just tweaking parameters

Proposal

I would like to hear what maintainers of this repo think about the best approach. Can we come up with a roadmap of how jaeger-v2 could be supported? Is there some common approach we can use with OTEL (https://github.com/open-telemetry/opentelemetry-helm-charts)?

Parallel ticket for Operator: jaegertracing/jaeger-operator#2411

Open questions

• Is it worth maintaining both helm charts and operator?

[yurishkuro]

cc @Stevenpc3 - you recently booked issues, any thoughts on the helm vs. operator question?

[Stevenpc3]

Unfortunately for the system I am working in we are currently not able to easily use the operator because our development on the clusters we have get shipped to other (generally air gapped) clusters we don't control and since the operator needs applied at the cluster level with admin it becomes a complex point for us to lose control and synchronize with the other envs we don't control.

So the solutions we develop tend to be as standalone as possible. I personally see a lot of benefits with the operator approaches but we cannot use it. I require the helm charts and will for a long time.

Mostly we make "wrapper" umbrella charts that have the jaeger chart as a dep. So we make like Jaeger-Tracing a chart for example to generate our own templated configs and our own ingress for Istio VS and NGINX and our secret templates and even our own keycloak that we then pass on to the Jaeger chart. Honestly, I would love to get a lot of it into the chart directly, but it's hard to flow it back. We wrap all of the charts because we either use directly which tends to severely lack, we fork and copy which is a nightmare to update or we wrap and do a hybrid to extend the charts. We haven't moved into using operators other than one item so I am not sure how hard it is to extend or wrap or if it's even needed.

I am also behind on the Jaeger V2 since this is only a small part of my overall responsibilities. Plus, I am not sure I get the question lol. I mean both would be nice if that is the question. Let's just say our customers very much need these tools and we are stuck with helm charts for a while.

I just reread and I am not familiar with the opentelemetry-helm-charts ( I just viewed them ) but I do like the idea of a single image and passing only config files. That would be super easy to make a wrapper chart for to generate our own configs. We could make a config.yaml for each (collector, query, etc) and then a template to generate or update that as we need. I am not sure about operators, but this would work well for how we do things.

"Is it worth maintaining both helm charts and operator?" yes. Selfishly as pointed out above. We will be using charts for at the very best case at least another 2 years?

[Stevenpc3]

We are venturing into using operators. I mentioned before we deploy to environments where we don't have control over the Paas we run on or full permissions, but under agreements we expect to be able to apply the CRDs to the cluster then we will likely be able to run operators via namespace restrictions. This is good, but we will still require helm charts. This would mean we would expect to be able to change over to using the jaeger-operator helm chart https://github.com/jaegertracing/helm-charts/tree/main/charts/jaeger-operator in the future.

As we move into a more GitOps approach we will be using ArgoCD now so applying configs is more simple. But we have various environments that get more and more restricted as we proceed right. So there is always a transition period from updating new processes.

I can only thank you for your efforts and your tools and offer a suggestion that deprecation goes a long way towards helping us and others move towards new capabilities, but those capabilities must work or we become stuck in an EOL product because we can't move forward on occasion due to product issues. So, even if the plan is to NOT support certain items... having a deprecation roadmap would be a great option. This gives us the tools to argue for movement.