In order to support the multiple consumers we plan on having, such as a possible unified observability experience and potentially the OpenShift Developer Console, we need to establish a Query API for them to use. This might benefit Kiali as well.

The Jaeger UI from the community can be the first consumer of this API, as it’s currently the case. As discussed in the Jaeger Community, we should explore the idea of providing a GraphQL interface to serve as our Query APi.

A proposal for the API has to be submitted to the community by 2021-06-01. In case the community isn’t interested in this, our internal proposal has to be done by no later than 2021-07-01. This work might have some prerequisites, such as jaegertracing/jaeger#2531.

The initial proposal doesn’t have to cover all the use-cases we have in mind. Rather, it should include the basic operations, reflecting what can be done with Jaeger today, plus what we think is critical for the downstream consumers in the near future (end of this year). The Jira item TRACING-1902 has been created during the virtual gathering, after private conversations between Juraci Paixão Kröhling and Christian Heidenreich, following up Juca’s question on “What do you need from us, distributed tracing team? How can we help you?”. 

Having this goal will help with the “Extension Points” parts of the strategy. 

This requires effort only from our team.