x

[dylankyc]

[yurishkuro]

We have no plans to support Pulsar.

[addisonj]

@yurishkuro a few questions for you:

1. Do all these backends need to live inside jaegar core? From what I can see at the moment, it looks like they are all in core but was curious if alternatives exist for "external" storage backends or if you have plans for such a mechanism in the future
2. Supposing that members of the pulsar community were interested in helping to develop and maintain a pulsar adapter, would that be contributions you would be willing to accept? I certainly understand that the complexity is more than just the code (such as CI, etc) but just wanted to get a sense for you all view that.

Thanks for your time, just trying to understand the best model for being able to support Pulsar in the long term :)

[yurishkuro]

Pulsar is not a (storage) backend, it can only be used as a queue. For storage backends we have a grpc plugin framework, so that the plugins can be developed outside of Jaeger core and don't have to be in Go. We do not have similar plugin framework for Kafka, it is integrated directly in the core. We prefer not to add anything more to the core due to maintenance burden.

Basically, we're limited by the original choice of Go as the implementation language, which has no good facilities for in-process plugins.

But we can open this for discussion.

[jpkrohling]

Starting with Jaeger v2, we should have an easier way for people to build their own Jaeger distributions incorporating their own storage plugins, possibly using the OpenTelemetry Collector Builder.

That said, the biggest issue with accepting new storage mechanisms is in terms of maintenance: making sure the build is working at all times, providing tests (unit, e2e), documentation, and taking care of community requests (issues, feature requests). Even if we find a team that wants to take care of this, we can't be sure this is still going to be the case in the future. If this team becomes unresponsive, we'd have a storage mechanism that we "have" to support ourselves.

If someone, or a team, is willing to take care of that, and if we can be convinced that this team is doing this for the long term, I think we can consider adding another storage to the core.