Deprecate jaeger exporters

[jack-berg]

Resolves #5096.

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: -0.24 ⚠️

Comparison is base (6ab37f1) 91.35% compared to head (4ea53d1) 91.11%.

❗ Current head 4ea53d1 differs from pull request most recent head ef1de6e. Consider uploading reports for the commit ef1de6e to get more accurate results

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5190      +/-   ##
============================================
- Coverage     91.35%   91.11%   -0.24%     
+ Complexity     4969     4886      -83     
============================================
  Files           552      549       -3     
  Lines         14581    14420     -161     
  Branches       1358     1380      +22     
============================================
- Hits          13320    13139     -181     
- Misses          872      891      +19     
- Partials        389      390       +1     

Impacted Files	Coverage Δ
...porter/jaeger/thrift/JaegerThriftSpanExporter.java	81.13% <ø> (ø)
...jaeger/thrift/JaegerThriftSpanExporterBuilder.java	84.61% <ø> (ø)
...emetry/exporter/jaeger/JaegerGrpcSpanExporter.java	87.09% <ø> (ø)
...exporter/jaeger/JaegerGrpcSpanExporterBuilder.java	80.64% <ø> (-1.18%)	⬇️
...aeger/internal/JaegerGrpcSpanExporterProvider.java	100.00% <100.00%> (ø)

... and 166 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[mateuszrzeszutek]

🎉 🎉 🎉

[jkwatson]

There's no reason these wouldn't keep working in the future, correct? We'll make sure our exporter APIs are stable, so these should keep working, if all is well.

[jack-berg]

There's no reason these wouldn't keep working in the future, correct?

Are you asking if after deprecating and eventually remove these, folks would continue to be able to use old versions of the jaeger exporters with new versions of the SDK?

If so, its actually not as good of a story as I would like. The opentelemetry-exporter-jaeger depends on internal APIs in opentelemetry-exporter-common. If those APIs were to change, the exporter would break.

The opentelemetry-exporter-jaeger-thift does NOT make use of opentelemetry-exporter-common so is relatively safe. Although it delegates the work to the deprecated io.jaegertracing:jaeger-client client library, which presents its own problems.

[jkwatson]

There's no reason these wouldn't keep working in the future, correct?

Are you asking if after deprecating and eventually remove these, folks would continue to be able to use old versions of the jaeger exporters with new versions of the SDK?

If so, its actually not as good of a story as I would like. The opentelemetry-exporter-jaeger depends on internal APIs in opentelemetry-exporter-common. If those APIs were to change, the exporter would break.

If users won't be able to use the exporter, then we definitely shouldn't include the older version in the bom still, since that would imply (I think) that it should work.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[jack-berg]

Re-opening this PR now that the jaeger exporter has been removed from the specification (open-telemetry/opentelemetry-specification#3567).

I've adjusted deprecation policy to keep security bugfixes until 1.34.0 (6 months), and no changes (security or otherwise) after. This reflects the policy of the native jaeger clients, and we should need to hold ourselves to a stricter standard.

[breedx-splk]

I think this is cool, and pretty generous on the timeline. As long as we think the maintenance should remain minimal, this approach should be fine.

The ongoing risk is some future CVE in the jaeger-clients dependency tree in the next 6 months. I think the mitigation is to either fork the deprecated repo and temporarily provide an internal fix, or (if I remember) build the protobufs ourselves. Hopefully neither of those will be necessary. 🤞🏻

[jack-berg]

The ongoing risk is some future CVE in the jaeger-clients dependency tree in the next 6 months.

Luckily its only opentelemetry-exporter-jaeger-thrift which relies on the jaeger-clients, and the usage of thrift is significantly lower than protobuf: