Roadmap

[pavolloffay]

This repository was created to address jaegertracing/jaeger#3500 with the proposed design https://docs.google.com/document/d/1d7j956tDVYacKHF-l0JL9sVhpbYkt0JECDyGeup-olc/edit#heading=h.n0e2aq0560x

The ultimate goal is to migrate all Jaeger storage implementations:

• in-memory
• Cassandra
• Elasticsearch (drop support for ES5)
• gprc-plugin

and expose Jaeger query/UI as:

• query extension

The storage exporters should translate OTELcol pdata struct directly to the model that is used by the storage layers (e.g. do not use existing translators from pdata -> jaeger model -> storage model).

[yurishkuro]

@pavolloffay could we downscope this list (maybe in another issue) to the minimal set of changes required for a POC with just one storage type, but otherwise having end-to-end usability of the Jaeger backend?

Once we have the e2e POC, migrating the rest of the components will require less "discovery", more of a mechanical work that can be modeled after the work in the POC, and thus it will be much easier to crowd-source.

[yurishkuro]

Alternatively, organize scope into milestones that allow incremental delivery. For example:

• M0: viability POC,
• M1: e2e POC for one storage type,
• M2: surrounding tooling like operator/helm,
• M3: more storage backends,
• etc.

Define clear success criteria for each milestone.

[pavolloffay]

Doing this incrementally with milestones is a perfect idea.

Could you please explain the M0: viability? Is this something that we already have?

M1: e2e with one storage type I would vote to start with in-memory.

[yurishkuro]

For the viability milestone I was thinking of something that proves that the overall goals are achievable, such as the build infra, whether we can incorporate query service (which is somewhat outside of the scope of OTEL pipeline), resolve any circular dependencies we used to run into.

[pavolloffay]

I don't expect any issues with circular dependencies now. If there will be we should be able to resolve those.

The query should be done via extension like the design doc outlines. I do agree that we need to build POC, probably with some in-memory or mock storage first.