Default global propagators

[carlosalberto]

Now that OTEP 66 was merged, we need to decide what the default global propagators need to be, either no-op or something meaningful (like TraceContext/CorrelationContext).

See: #208

[Oberon00]

How has the situation changed here with OTEP 66? Some default HttpTextFormat or equivalent had to exist even before.

[carlosalberto]

I know a few languages already had TraceContext (W3C's) in the API package, and were exposed in their DefaultTracer already ;) (I know in Java we have this, but only us).

[dyladan]

In JS the TraceContext propagator is in the SDK package not the API package. As far as I'm aware, this is the case for most of the SIGs. Additionally, in JS context management is no-op by default, which means even if the propagator extracted a value, it would be added to a no-op context and dropped. At least in JS, we cannot have a default context manager that works in both web and nodejs. We could have platform-specific defaults if required, but this is not the way it currently works.

[jkwatson]

Sooo. What's the state of this issue? Someone needs to own it.

[carlosalberto]

I will own it. Will dig what's the state of this for each SIG and will re-start the discussion.

[Oberon00]

As per #208 (comment) I would suggest we stay with no-op.

[carlosalberto]

(I'm starting to feel having no propagators registered by default is the way to go - agents and similar layers can be the ones setting them as needed)

[Oberon00]

I think it should be easy (single function call or right package in classpath etc) to configure OpenTelemetry to act as transparent proxy, but it should not be the default.

[dyladan]

I will own it. Will dig what's the state of this for each SIG and will re-start the discussion.

A lot of the work to determine the state of each SIG has already been done on this issue.

#520

[iNikem]

My 2c: OTel should have sensible defaults so that it would do sensible things out of the box. Without requiring any configuration. Like using OTLP exporter to localhost:$defaultPort. And using W3C TraceContext propagator. Etc. Not forcing users to make a lot movements to get something working...

[Oberon00]

I think we have to discuss separately:

1. What should be the propagators if we only have the context layer? Probably no-op, since SpanContext, etc does not exist in this package.
2. What should be the propagators if we add the API artifact? I think if we have the API but not the SDK that indicates that some library with built-in OpenTelemetry support is used but the application does not configure or even know about OpenTelemetry. I think we should use no-op here to avoid surprises. Otherwise adding built-in OpenTelemetry support to any library will be a breaking, behavior changing change.
3. What should be the propagators if we add the SDK artifact? I think that having at least a pass-through propagator here would make sense.

[iNikem]

Without SDK and without auto-instrumentation - no-op, agreed. As soon as we have SDK or auto-instrumentation we should propagate context even if we don't do anything ourselves in this process. We just should decide which wire format to use. My vote goes to W3C TraceContext.

[jkwatson]

@carlosalberto can we get a status update on this?

[carlosalberto]

@jkwatson hey, thanks for asking. I have a draft proposal locally that I will send as a PR tomorrow (and FYI, in the proposal we go propagatorless by default).

[jkwatson]

@jkwatson hey, thanks for asking. I have a draft proposal locally that I will send as a PR tomorrow (and FYI, in the proposal we go propagatorless by default).

Great. I'll start work on a PR for #689 assuming that will be the case. Thanks for the update!