otlp receiver expects traces on “/v1/trace” but spec says “/v1/traces”.

[tigrannajaryan]

Probably need to fix this gracefully by adding “/v1/traces” as an alias, then removing “/v1/trace” in a few months after announcement.

[bogdandrutu]

I think this gets very ugly:

• gRPC traffic uses v1/trace path
• HTTP traffic uses v1/traces path

Probably it is good to proceed and change both gRPC, HTTP to use v1/traces.

Here is a possible plan to do this in a backwards compatible way:

1. Change protos to use the new path with v1/traces, but also keep the gRPC service definition that we currently have (will use request and response objects from the new path).
2. Change receivers to install both, this will make the receiver be able to receive on v1/trace and v1/traces both traffic gRPC and HTTP. This is backwards compatible.
3. Change the otlp (gRPC) exporter to:
   • First try to send to the new service path. If status returned is "Unimplemented" fallback to the old path.
   • In few months remove the fallback path.
4. Change the otlphttp not necessary.

[tigrannajaryan]

@bogdandrutu I was initially thinking to keep gRPC unchanged for 2 reasons:

1. The OTLP spec does not say anything explicitly about OTLP/gRPC path. It does explicitly say what the path is for OTLP/HTTP.

2. OTLP/gRPC does not use /v1/trace, it uses /opentelemetry.proto.collector.trace.v1.TraceService/Export as the path. So, although it would be nice to have OTLP/gRPC path also use singular "trace" in it, I don't think it is a big deal. It is a different path compared to OTLP/HTTP anyway and whoever needs to deal directly with the paths is not going to be able to use one value for both OTLP/HTTP and OTLP/gRPC protocols (for example in a hypothetical scenario when they need to map the paths in the proxy to something else).

Because of the above 2 reasons I suggest that we don't change anything in OTLP/gRPC and keep it as is. We only fix the path in OTLP/HTTP. Here I was also initially thinking about a graceful, so that both paths are supported by receivers for a while, but now I think that even that is not necessary. OTLP/HTTP implementation was added to Collector just a few days ago, it is not even released. It is very likely that nobody in the wild is using this protocol yet so it should be OK to fix the bug without attempting to maintain compatibility with previous incorrect version of OTLP receiver.

What do you think?

[tigrannajaryan]

I can look into implementing the fix for OTLP/HTTP in a graceful way, and keep accepting the old path in the receiver for a while, but it may complicate the fix.

[tigrannajaryan]

Fix for OTLP/HTTP only with graceful handling of both old and new path in OTLP receiver: #1979