Requirement

In order to e2e test gRPC storage we need a binary that implements the gRPC Storage API. For v1 we had remote-storage binary that performed that function. It provided a Remote Storage API facade on top of any other storage implementation supported by Jaeger.

Problem

remote-storage was built for v1 storage implementations and is only configurable via CLI flags (same as v1 collector). To align this with v2 collector the configuration should be similar to jaeger-v2, and the binary should support v2 storage implementations (falling back to v1 when needed)

Proposal

Use a dedicated v2 config to run jaeger-v2 binary to play the role of remote storage. We need two things for that:

1. An OTLP receiver (we can probably use the standard one)
2. An extension that can serve Storage V2 read API
3. Ideally those two should be listening on the same port

The last point is not directly possible with OTEL Collector framework. But we don't have to have that, we could relax v2 gRPC storage implementation to allow two different ports for read and write path.

For the extension we can copy how query extension is done. It needs to perform the same functions - have access to the actual storage implementation (like memory or ES) via jaeger_storage extension and open a server port with Storage V2 read API.

We already have cmd/jaeger/config-remote-storage.yaml for a collector utilizing remote storage. We can create another one cmd/jaeger/config-remote-storage-backend.yaml with the above.

Open questions

No response