Opentelemetry-specification: What is the API behavior of Baggage in the absence of an SDK?

[jkwatson]

What are you trying to achieve?

I'd like to understand what the behavior of the Baggage API is in the absence of an installed SDK. No-op like spans? Full functionality like the Context? Something else?

[andrewhsu]

from issue triage mtg today, need to arrive at decision for whether we have a noop or the behavior defined

[mwear]

My 2 cents is that we should do the same for Baggage as we do for W3C trace context. It would be ideal if the API can propagate Baggage without an SDK as long as it was configured to do so.

[jkwatson]

Is there anyone who feels that the Baggage should be a no-op without the SDK installed? If no one will speak up on behalf of this option, I can go ahead and add a note to the Baggage API doc that clarifies that Baggage in the API should be fully functional.

[carlosalberto]

I'm also in favor of doing Baggage support at the API level.

cc @bogdandrutu as he may know why, for reference, why we decided to have this as no-op for Java.

[Oberon00]

Sorry to bring up this fundamental question, but I think we are again lacking a document describing the motivation for the SDK/API split. That makes it very difficult to decide such questions. For example, if one purpose of the API/SDK split is to allow libs to instrument themselves with OpenTelemetry everywhere then we would need to really double down on keeping code in the API minimal. We would have to assume that 3rd party libs everywhere depend on some API version and having to push any update to the API might be painful.

I don't know how complex baggage support is to implement. If it's basically just a wrapper around a map, then it's probably fine in the API. If it's more, then probably not.

What about cross-process baggage propagation? IMHO it should still be no-op even if we decide to put baggage itself in the "API", otherwise it gets confusing in combination with spans.

One more thing: If baggage is a completely implemented API in the API, then baggage API == baggage SDK. In that case, I would say that we don't want the API/SDK split for baggage and should split baggage out in it's own artifact (that depends only on the context layer).

[Oberon00]

My 2 cents is that we should do the same for Baggage as we do for W3C trace context. It would be ideal if the API can propagate Baggage without an SDK as long as it was configured to do so.

But that is not the case for trace context, is it? The W3C propagator is not part of the API. Reading https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/context/api-propagators.md, I think we are currently only prescribing Jaeger and B3 but not W3C propagators, which seems like a defect to me.

[SergeyKanzhelev]

My 2 cents is that we should do the same for Baggage as we do for W3C trace context. It would be ideal if the API can propagate Baggage without an SDK as long as it was configured to do so.

But that is not the case for trace context, is it? The W3C propagator is not part of the API. Reading https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/context/api-propagators.md, I think we are currently only prescribing Jaeger and B3 but not W3C propagators, which seems like a defect to me.

W3C must be in this list as well. I think it was lost as initially W3C was required to be a default implementation and it wasn't mentioned again in that list.

[carlosalberto]

@Oberon00 They are indeed mentioned, e.g. https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#included-propagators and similarly for its Baggage counterpart. Maybe we can think about putting all in the same location, but that's more of an improvement.

[Oberon00]

In https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#included-propagators we only have a MAY for W3C, not even a SHOULD. EDIT: But this is going off-topic here. EDIT2: Created #1093 EDIT3: Hid related comments as off-topic, hope that is OK.

[carlosalberto]

In that case, I would say that we don't want the API/SDK split for baggage and should split baggage out in it's own artifact (that depends only on the context layer).

Not necessarily. In the tracing API we expose some logic regarding SpanContext (in order to, among other things, support propagation at the API level): trace and span id encoding, sampled information (even if minimal), etc. And given the fact Baggage would be basically an immutable Map, the amount of logic there is not much.

For example: in Java, SDK's Baggage takes 172 lines of code, whereas SpanContext.java in the API takes 163.

[andrewhsu]

from the issue triage mtg today, talked about this and assigning to john to carry

[jkwatson]

I haven't seen anyone chime in that baggage propagation should require an SDK, only some lack of clarity about how we make this kind of decision.

With that in mind, I'm going to PR a change to the spec that adds the requirement that the Baggage API is fully-functional, even without an SDK. That is, that the APIs implementation of Baggage should be enable cross-process baggage propagation in the absence of an installed SDK.

[Oberon00]

With that, is there any benefit in splitting the baggage into API and SDK?

[jkwatson]

With that, is there any benefit in splitting the baggage into API and SDK?

I don't think so. I think it's an API-only capability at this point.