Migrate Query Service Handlers to Use v2 Query Service

[mahadzaryab1]

We want to migrate the following handlers to use the new v2 query service which operates on the OTLP data instead of the legacy models within Jaeger:

• v3_api GRPC: [api_v3][query] Change api_v3 grpc handler to use query service v2  #6452
• v3_api HTTP: [api_v3][query] Change api_v3 http handler to use v2 query service #6459

[yurishkuro]

We should brainstorm how to solve v2_api GRPC / v1 (HTTP). They are both legacy APIs that are fundamentally built around v1 data model. Some options we have:

1. upgrade them to use QSv2 directly and translate data back into model
2. allow them to continue using QSv1 but re-implement it as a wrapper on top of QSv2

I think option (2) is a better path, because it minimizes the changes to these two legacy handlers, without significant rewrite. The mains can only instantiate QSv2 and pass it to those handlers, and the handlers will internally instantiate (a stateless) QSv1 adapter, thus isolating the scope of QSv1 API.

[mahadzaryab1]

@yurishkuro I'm leaning a bit more towards Option 1, especially because we already have this helper implemented. It would also allow us to get rid of the v1 query service altogether. What do you think?

[yurishkuro]

We can still use that helper inside renewed QSv1. That way to only need to change QSv1, but if you go with option 1 you would need to invoke those additional transformations from the handlers - more changes.

[yurishkuro]

In fact, but moving this logic into QSv1 we can leverage it 4 times: the handlers above plus cmd/remote-storage and cmd/anonymizer. So I would definitely start with that and then each of the 4 callers can be upgraded directly to QSv2 independently as (and if) needed ("if" because I don't think it makes sense to spend time upgrading v1 and v2 handlers, since they ultimately need to return v1 data model anyway). The two other callers (binaries) are TBD.

[yurishkuro]

I was thinking more about this, how to minimize the transformations. See related issue #6474 for the write path.

Similar to the write path, the read path for APIv3 is already "optimal" in terms of how many data transformations we do - if the storage is native v2 then we get OTLP directly, if the storage is adapter over v1 then we do one extra transform, exactly what happens in the query service today anyway.

For v1 and v2 APIs, however, we are getting back into multiple unnecessary transformations situation, but we can also avoid that. My proposal is:

• keep v1 query service as is, operating on v1 storage
• make the constructor of query service accept v2 storage only
• the constructor should check if v2 storage is actually an adapter over v1, if so retrieve v1 reader and operate as usual
• otherwise, apply another adapter that wraps native v2 storage into v1 reader API

This requires minimal changes to the QSv1 implementation, only the constructor must change. And it requires no changes to the legacy v1/v2 api handlers. And the amount of data transformations is minimized.

[mahadzaryab1]

@yurishkuro +1. I'll get started on this upgrade