Add EnvironmentCarrier for propagating trace information across processes

[moskyb]

This PR: Adds a default TextMapCarrier to the propagation package, EnvironmentCarrier. The purpose of this carrier is to propagate trace information cross-process, most notably in the case of tracing CI runs.

[linux-foundation-easycla]

• ❌ - login: @moskyb / name: Ben Moskovitz . The commit (12ed95a, 8eba28e) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[hanyuancheung]

Pls don't forget to sign the CLA.

[hanyuancheung]

invalid blank line. Pls remove it.

[moskyb]

will do!

[dmathieu]

Setting environment variables with nothing prepended to them is quite unsafe (somebody could override PATH by mistake for example).
How about setting up a namespace? OTEL_CARRIER for example?

[moskyb]

yep, that makes sense to me. so long as it's transparent to the user (ie, we add it before setting an envar and remove it before presenting it to the user), that's totally fine by me

[dmathieu]

While the idea is interesting, I think this would need to go through an otep to have a formal specification, so it can be implemented the same way in every library.

[MrAlias]

Thanks for your interest in the project. I do not think using globally defined environment variables to communicate intra-process cross-cutting concerns will work outside of the simplest of use cases. Regardless of that, @damemi correctly points out that this addition will require compatibility across OTel language implementations and therefor will require an OTEP and eventually a specification addition before we would be able to accept this change.

I'm going to close this based on this pre-mature state of the concept. Please feel free to re-submit when there is consensus for this addition from the specification.

[moskyb]

I do not think using globally defined environment variables to communicate intra-process cross-cutting concerns will work outside of the simplest of use cases

@MrAlias can you elaborate on this a bit? the key usecase for me is tracing CI runs, where in some cases, the only way to communicate with a job being run is by environment variable - for example, if we were tracing our tests, there isn't really a place for the tests to get information about what ran them other than the process environment.

For full disclosure, i work at Buildkite, a CI provider, and a feature we're working on at the moment is OpenTelemetry support. I really think that this could be useful across the CI landscape though, and useful in general when one process is starting other processes, and we want to propagate traces across them

[MrAlias]

I do not think using globally defined environment variables to communicate intra-process cross-cutting concerns will work outside of the simplest of use cases

@MrAlias can you elaborate on this a bit? the key usecase for me is tracing CI runs, where in some cases, the only way to communicate with a job being run is by environment variable - for example, if we were tracing our tests, there isn't really a place for the tests to get information about what ran them other than the process environment.

For full disclosure, i work at Buildkite, a CI provider, and a feature we're working on at the moment is OpenTelemetry support. I really think that this could be useful across the CI landscape though, and useful in general when one process is starting other processes, and we want to propagate traces across them

You will be limited by the unique nature of environment variable. It is not possible to communicate multiple cross-cutting concerns across multiple propagation pathways using this mechanism, at most it can hold the state for one.

If this solves your issues though, I would encourage you to use it. We designed the TextMapCarrier interface to be extensible for just such experimentation and extension. If you do find large community adoption, please feel free to submit the idea as an OTEP for ratification into an OTel standard.