Deprecate/remove opentracing lib

[phlax]

There has been the intention to remove this lib for some time

There were some issues with the build, but #27400 fixes it for now so we can retain and deprecate properly

[phlax]

cc @moderation @Oberon00 @kyessenov

[phlax]

related to #9958

[RiverPhillips]

Before we deprecate existing tracers is it possible to clarify the security posture of OpenTelemetry? #24672

[Oberon00]

It would also be cool if envoy could support OpenTelemetry OTLP over HTTP (in addition to the current gRPC) before that, see also #9958 (comment)

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[yanavlasov]

Before we deprecate existing tracers is it possible to clarify the security posture of OpenTelemetry? #24672

The security posture has been changed to unknown since there the upstream OT repository is frozen.

[Oberon00]

Hi, just to confirm, in the current main branch, before 1.29 is cut, the hard deprecation will happen where an override is required to still access the functionality?

[Oberon00]

@RyanTheOptimist @phlax At the moment at Dynatrace we are making plans assuming the hard deprecation is merged in 1.29, can you confirm this is actually planned?

This matters for Dynatrace because we need special handling for the version(s) where the config option causes startup to abort without the deprecation override but OpenTracing is still detectable in the binary. As long as >=1.30 actually has OpenTracing removed completely from the binary, that will be fine, but if that version slips due to not adding a hard deprecation in 1.29 we would need to make adjustments.

[joaopgrassi]

@wbpcode do you maybe know anything about the above?

[phlax]

can you confirm this is actually planned?

afaiaa this is planned and i think messaging was sent out to this effect altho i think most likely it will be after 1.29 is cut

[joaopgrassi]

@phlax

afaiaa this is planned and i think messaging was sent out to this effect altho i think most likely it will be after 1.29 is cut

Alright so, reading https://www.envoyproxy.io/docs/envoy/latest/configuration/operations/runtime#using-runtime-overrides-for-deprecated-features and https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md#breaking-change-policy I understand the deprecation cycle as follows:

• First phase: mark as deprecated (✅ done in 1.28)
• Second phase: Disallow feature by default, by adding the disallowed_by_default annotation (❌ not done yet on main thus not part of 1.29)
• Third phase: Remove the fields completely (1.30?)

Is my understanding right? If so, that means phase two will be 1.30 and phase three 1.31?

[phlax]

@joaopgrassi this seems correct to me - but seeing as we are slipping a version can we prioritize adding the deprecation as soon as 1.29 is cut?

[joaopgrassi]

but seeing as we are slipping a version can we prioritize adding the deprecation as soon as 1.29 is cut?

@phlax This means then the disallowed_by_default behavior would only be enforced on 1.30? That seems totally fine. Would be great also for us at Dynatrace and our customers.

[phlax]

i think that is fine, as long as we prioritize the deprecation soon after release

[joaopgrassi]

i think that is fine, as long as we prioritize the deprecation soon after release

Sounds good to me!

[alyssawilk]

ok deprecation went through, and we're a couple releases past the original warning point so I plan on removing this soon.
Please let me know if there are any remaining concerns.