Configuring propagators by environment variable

[mwear]

Background

This is issue is similar to #679, but deals with propagator configuration and has some additional considerations.

#666 allows configuration of propagators via and environment variable where the value is a comma delimited string. In order for this to work, there must a way to instantiate or look up a propagator using a string. Since this is an extension point, users will need a way to register custom propagators. Having a propagator registry is one way to accomplish this. There are likely other strategies that will work. Please discuss in the comments if you have other ideas.

Environment Variable Name

This is the currently proposed name and format

Name	Description	Notes	Default
OTEL_PROPAGATOR	Propagators to use as a comma separated list	E.g. tracecontext, b3, b3,tracecontext	tracecontext

Note: We will need to define a canonical name for each propagator. Is lower snakecase a reasonable choice for built in propagators, or should we choose something else?

Open Questions

What should be done in case of failure?

• What no names match the configured value?
• For the comma delimited case
  • What if some names match, but some do not?
  • Should whitespace be allowed, removed?

[Oberon00]

Note that a major open point here is that we currently don't really support more than one propagator at a time, see #496.

I also think that it should be possible to configure extractors and injectors separately (it's likely you want to be able to read different formats but still write only W3C, for example). This is also not well-supported by the propagator API currently, however.

[carlosalberto]

I also think that it should be possible to configure extractors and injectors separately (it's likely you want to be able to read different formats but still write only W3C, for example).

Not all languages support separated injectors/extractors (Java doesn't, for example). But the case you mention on reading different formats but write only W3C could be supported in a MultiTracePropagator (through a flag specified at builder time, e.g. builder.setWriteFirstOnly()), as @jkwatson already mentioned somewhere.

[carlosalberto]

Also, observe that this should support canonical formats for other signals, such as CorrelationContext ;)

[Oberon00]

True, the MultiTracePropagator could simply have separate lists of propagators for Inject/Extract.

[carlosalberto]

I'm interested in this issue, so I will take this on me.

[tigrannajaryan]

Do we still consider this to be a must-have for GA?

[carlosalberto]

Changing this to P1 after talking to the Java Instrumentation Maintainers.

[trask]

can you assign to me? thx

[trask]

Since this is an extension point, users will need a way to register custom propagators.

@carlosalberto I don't think this is the issue that I thought it was. We don't need custom propagators in Java Instrumentation for GA.

[iNikem]

But this PR is not only about custom propagators, right? It includes built-in ones.