Instrumentations and overriding Propagator

[cijothomas]

#581 is resolved as we added Global Propagators API which allow one to retrieve the Global propagator, and SDK sets the default to Composite (Baggae, TraceContext).

Opening this issue to discuss if we need to still allow Instrumentations to override their Propagator. Its not really mentioned in the spec, but there could be use cases where a specific instrumentation requires non-default propagator.

[eddynaka]

Question: is it common for people to enable different Propagators for different instrumentations? For example:

• http -> w3c only
• aspnetcore -> all

If we go to the way where we remove the propagators from options, that won't be possible anymore unless u start many SDK's and, in each SDK you add one instrumentation or something like that.

[cijothomas]

yes, if we remove the propagator from individual instrumentation options, then every instrumentation get the same global propagator with no ability to override. Spec doesn't say that instrumentations may ignore the global propagator either. So its upto us for now, to decide if we want to allow this or not.

I am okay to remove this for now, and if a need comes up, we can always add it then. (The reverse is not easy after GA.)

[cijothomas]

From today's Sig meeting: Remove the option from instrumentation.
Keep an issue open for adding back if required after GA.
This is done to make sure we dont expose any public API unless there is strong reason and the requirements are clear.