OpenTracing layer support for Baggage #2137
Labels
area:miscellaneous
For issues that don't match any other area label
question
Question for discussion
spec:miscellaneous
For issues that don't match any other spec label
In OpenTracing,
SpanContext
andBaggage
are part of the same object, whereas in OpenTelemetry they are different objects. This would be straightforward and trivial to support if the OpenTracing Shim couldn't be used along the OpenTelemetry API in the same code base -- which, however, has been deemed important to support gradual adoption in large codebases.This currently is supported in the OpenTracing Shim by associating any OpenTelemetry
Span
with a givenSpanContext
+Baggage
combo at all times, in order to see changes reflected in different threads at all times. A typical use case isThis is supported in Python easily by decorating a pair of values in the OpenTelemetry
Span
itself, whereas in Java (and similar languages) it requires a global map with a global read-write lock, which may still impact the performance greatly.Alternative 1
Completely discard support for Baggage, providing the related functionality as no-op, given:
SpanContext
baggage values are copied from the the parentSpan
).Alternative 2
Provide a best-hope design, in a relatively simplistic fashion, in order to handle common cases (such as an OpenTracing
Span
being created, have its baggage set, and have its baggage propagated).SpanContext
+Baggage
be part of theSpan
Shim object (hence, no need for global maps/locks), and propagate this object itself (along its currentBaggage
). This would allow:Baggage
.Baggage
value as needed.Context
has noSpan
Shim object, all the OT Shim Baggage operations are no-op.This WOULD NOT satisfy the expected OT Handling, but it would offer limited support though.
cc @yurishkuro @tedsuo
The text was updated successfully, but these errors were encountered: