Define the list of built-in propagation formats

[bogdandrutu]

1. Define the list of propagation formats that the OpenTelemetry will officially support, proposal:
   • W3C for trace https://github.com/w3c/trace-context
   • W3c for tags/baggage https://github.com/w3c/correlation-context
   • B3, do we commit to support this?
   • Jaeger, do we commit to support this?
2. Where does the implementation for each format live?
   • In API?
   • In SDK?
   • In contrib?

[austinlparker]

Related to the first point, what about x-ot headers? Maybe have the API support a list of propagators with a default implementation of the W3C spec in SDK, then support B3/Jaeger/etc. through contrib?

[bogdandrutu]

Where is x-ot header defined?

[austinlparker]

I don't think it's actually defined anywhere (and whoops, it's actually ot-tracer-*), but there's quite a few usages of it: https://github.com/search?q=ot-tracer-traceid&type=Code (although a lot of these seem like they're just gists...)

I'll see if I can find a canonical reference for it, might just be something that got decided in issues when talking about mock/noop tracer implementations.

[bogdandrutu]

So if there is a specification of these protocol, we can definitely support it (without a specification we cannot support it).

Do you know if anyone uses this in real production or is just define for no-op testing Tracers?

[austinlparker]

Yeah, I know of some LightStep customers that use it. Presumably others do as well via Envoy/Veneur/Istio/etc. I'll see if we can get it codified into a spec somehow.

Alternately, I think it'd be fine if this was only supported by the opentracing bridge as a legacy protocol. That might be the most straightforward way to handle it.

[austinlparker]

I talked this over internally and our consensus is that ot-tracer headers shouldn't be supported in the core API/SDK, so no need to consider them for this. I think, from a maintainability perspective, it makes the most sense to have a single blessed W3C implementation in core and then address B3 and others in contrib.

[iredelmeier]

re: where exporters should live - my inclination would be to put W3C support as close to core as makes sense, e.g., a standalone library that is also exposed as the default by SDKs. Anything "non-standard" - B3, Jaeger, legacy protocols, etc. - should not be part of the core SDK, so that versioning (especially deprecating!) is decoupled.

[rochdev]

I'm not sure I understand what's the difference between W3C format and other formats, other than it being standard. As a user, why would I want to always pull W3C if I'm not going to use it for example?

[jmacd]

Note that the Go repo recently moved propagators into the API. This may make it difficult to remove support for these formats in the future: open-telemetry/opentelemetry-go#362

[tedsuo]

API vs SDK

I like the original list, as far as SDK support. I also don't see an issue with expanding it to include more as people request them - but only in the SDK. It does not seem like these need to be in the API? I'd like to see examples of why that would be necessary. If we are putting constructors for some of these in the API, it should be a very short list - I would only suggest B3 and W3C. Otherwise, every implementation will have to implement an old Jaeger format until the end of time.

Some addition headers to consider supporting

There are headers defined in Envoy, which I'm not a fan of. But we need to either get envoy to retire them, or we need to support them: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#config-http-conn-man-headers-x-ot-span-context

@austinlparker FWIW the "ot-tracer-*" headers have their origin in the OpenTracing "basic tracers." LightStep also uses them. https://github.com/opentracing/basictracer-go/blob/master/propagation_ot.go#L22

[austinlparker]

Should the API just define an interface for propagators (inject and extract), and maybe the propagator stack, and then all implementations live in the SDK?

[tedsuo]

@austinlparker yes that's how I imagined it would work. Whether something is B3 vs TraceContext only arises in the constructor - the interfaces propagator interfaces are all in the API.

[jmacd]

Somehow I feel we should put the Names of these standard propagation formats into the API and the Implementations in the SDK.

[carlosalberto]

Btw, if we happen to provide out-of-the-box propagation with the default no-op Tracer (and Meter?), we might need to have at least W3C TraceContext in the API.

[jmacd]

I would be happy to state that I think a NoOp implementation should be a true no-op. If the user wants to disable tracing and metrics but continue propagating context in a pass-through way, they could install a propagate-only SDK with support for all the propagators they like.

[austinlparker]

Somehow I feel we should put the Names of these standard propagation formats into the API and the Implementations in the SDK.

This feels like it'd be great except for when people want to implement their own - for instance, what if someone writes a propagator for X-Amzn-*? We'd need to update the API, or provide a way to pass arbitrary names to the SDK.

[jmacd]

I have proposed we think of "named" propagators, yes:
open-telemetry/oteps#66 (comment)