As a skipper library user, I would like the ability to use OpenTelemetry API using the same abstraction skipper already provides through OpenTracingParams thus not introducing breaking changes to the library

[lucastt]

Is your feature request related to a problem? Please describe.

OpenTracing Spec is being deprecated in favor of OpenTelemetry Spec (OTel), as a result skipper would have to migrate to OTel eventually because OpenTracing will not be maintained for long. A problem that comes with this migration is that OTel SDK implements a different Tracer interface, which would impact some parameters passed down to skipper proxy that configure the Tracer.

Describe the solution you would like

OTel intends to be backward compatible with OpenTracing and to achieve this goal OTel implements a bridgeTracer, the bridgeTracer implements a translation of OpenTracing API to OTel API thus not braking implementations that depend on OpenTracing Tracer interface, like skipper does.

The solution I'd like to propose is to change skipper implementation to support OpenTelemetry but use bridgeTracer as a compability layer in order to not change the parameters used to configure the Tracer used by the proxy code.

Describe alternatives you've considered (optional)

An alternative solution would be to actually use OTel Tracer interface instead of OpenTracing one, resulting in a breaking change for skipper library users, but effectively migrating from OpenTracing to OTel.

Additional context (optional)

• Use OpenTelemetry instead of OpenTracing #2104

Would you like to work on it?

Yes.