Add "none" as a possible value to OTEL_PROPAGATORS

[pellared]

Per #2045 (comment)

Changes

Add none as a possible value for OTEL_PROPAGATORS to disable context propagation. Because the default is tracecontext,baggage, there is no way to disable signal export via env vars.

The same approach has been specified for OTEL_TRACES_EXPORTER and OTEL_METRICS_EXPORTER here: #1439

It is also important given the fact that an env var with empty env var should be interpreted in the same way as an usnset env var. More: #2045

[yurishkuro]

Please explain the need / document the use case for this setting.

Nit: given that this is a list of propagators, the value "none" seems a bit odd. It's fine when it is standalone value, but this setting allows composing propagators, such that none can be combined with something else. "noop" might be more accurate description of it, since it's not the absence of a propagator, but one that does nothing.

[pellared]

@yurishkuro Same use case like for span and metrics exporters. I am proposing none for the sake of consistency. This is also the only way to disable propagation via env vars.

Later I can try improving the description

[pellared]

@yurishkuro Description updated

[yurishkuro]

My concern is that by making this a requirement in the spec we're adding cumulatively hours to days of work for SDK maintainers, and doing it "for consistency" is not a strong enough argument. Is there a strong demand for this feature from end users?

Also, I find the wording (not introduced in this PR) of "these are known values" rather confusing - do SDKs must support all those values and the respective algorithms? We may want to book a separate issue to discuss that.

[carlosalberto]

Adding this to the next Maintainers call for further discussion.

[trask]

by making this a requirement in the spec we're adding cumulatively hours to days of work for SDK maintainers

is this a MAY here? e.g. xray is in this same list and is not a MUST. in which case SDKs could choose to implement it based on demand

[trask]

Also, I find the wording (not introduced in this PR) of "these are known values" rather confusing - do SDKs must support all those values and the respective algorithms? We may want to book a separate issue to discuss that.

oh yes, what you said 👍

[tsloughter]

Since none was already used I think this should go with none even if noop is better.

And would argue if there is a configuration that has a default that is used if it isn't set then there needs to be a way to set it to be a noop, even if many users haven't asked for it yet :)

[obecny]

in js this won't be a problem with propagator equal to none it will be already working fine and if propagator it not found it will show error but it will not harm the app.

[carlosalberto]

@open-telemetry/proto-go-maintainers A last look perhaps?