Should we allow "certified" storage backends that only expose Jaeger Read API?

[yurishkuro]

Historically our requirement for external storage was a write path from jaeger-collector and read path from jaeger-query (https://www.jaegertracing.io/docs/1.43/apis/#remote-storage-api-stable). These days, various storage solutions are implementing other ways of getting data in, usually via OTLP directly, and then only expose the Jaeger Read API (former example Promscale, new one Quickwit (#4362)). Previously I asked Promscale to implement the write path before including them as certified backend in the docs. Should reconsider this policy and allow read-path only implementations?

Pros:

• I expect this situation (avoiding Jaeger collector to write to storage) to become more prevalent in the future, so supporting this mode provides strategic alignment with OTEL
• In many situations, Jaeger collector does not provide much additional value being on the write path, so not requiring it makes it for easier setup for users
• We could eventually migrate away from our Write API for storage in favor of straight OTLP

Cons:

• Cannot use unique collector features like adaptive sampling since it won't have a write API
  • Remediation: we can add an "otlp" storage type to collector
• Our "certification" integration unit tests require writing to storage in order to validate later reads
  • Remediation: previous item would address this too