Allow AWS propagation format in OTEL distributions

[jack-berg]

The propagators distribution section describes the set of propagators that MUST and MAY be included in OpenTelemetry distributions.

There's explicit text that "vendor-specific protocols such as AWS X-Ray trace header protocol MUST NOT be maintained or distributed as part of the Core OpenTelemetry repositories.".

Note that the spec has gone back and forth on this. Initially, vendor specific protocols were embraced in core repositories. Later, that decision was reverted following this discussion in which it was decided that only only fully open standards should be in the main SDK repositories.

In java, we missed the boat on this and currently publish a stable artifact for the AWS X-Ray propagator. This directly contradicts the spec. We've been discussing a potential move and lately the consensus has been to keep the component where it is, and instead try to amend the spec to include it in the list of propagators that MAY be included in the core repo, similar to OT Trace.

I don't think its wise to revisit the general decision to separate fully open standards from vendor / platform specific standards, but
can we consider making an exception for the AWS propagator?

In java, the AWS propagator is included automatically in the javaagent, and I believe its quite useful for users. If we are forced to move it to opentelemetry-java-contrib, we'd have to continue publishing a duplicate deprecated copy from opentelemetry-java until some point in the far future where we reach a 2.0 release, which would be awkward.

[dyladan]

I suggest we just make a note in the spec that the java xray propagator is a known deviation from the specification (possibly with a short 1-liner reasoning). Making a spec exception for xray leaves the door open for other SDKs to implement it (which we want to discourage) and for other vendors to ask for their format to also be exempted.

[ahayworth]

For what it's worth, Ruby definitely missed this memo, but we are now back in spec compliance since we split off a -contrib repo. 😆

A preliminary search indicates that the @open-telemetry/rust-maintainers may wish to do something, since they have an XRay propagator.

[martinkuba]

In JavaScript, we recently moved the X-Ray propagator from the contrib repository to the core repository, only realizing afterward that this constraint existed in the specification.

The move was made to support xray and xray-lambda in the OTEL_PROPAGATORS environment variable. According to the Lambda specification, it should be possible to configure the X-Ray Lambda propagator via the OTEL_PROPAGATORS environment variable. Additionally, the specification states that xray is a recognized value for this environment variable.

In JavaScript, we cannot dynamically detect propagators at runtime, and the mapping for the environment variable is currently hardcoded in the SDK. Therefore, we decided to move the X-Ray propagators to the core repository.

Either making an exception for the X-Ray propagators or relaxing the requirement would be an easiest path forward for the JavaScript SDK.

[jack-berg]

In JavaScript, we cannot dynamically detect propagators at runtime, and the mapping for the environment variable is currently hardcoded in the SDK. Therefore, we decided to move the X-Ray propagators to the core repository.

This sounds problematic. Means you can't reference custom propagators in OTEL_PROPAGATORS.

In java, the AWS propagator is included automatically in the javaagent, and I believe its quite useful for users. If we are forced to move it to opentelemetry-java-contrib

We ended up going down this route so at least from java's perspective, this issue is now irrelevant.

Closing, but will re-open if anyone is still interested in some sort of exception being carved out.