Move Zipkin backports to another repository?

[yurishkuro]

518 introduced a pretty large, and largely unnecessary, dependency on github.com/go-openapi/* packages (https://github.com/jaegertracing/jaeger/pull/518/files#diff-395f41b2a27b70ce44399c91c82158c2R45).

What if we moved all Zipkin-related code into another repository and have people run it as a sidecar instead of being part of the main Jaeger collector?

Alternatively, we should consider if we really need all these runtime dependencies on github.com/go-openapi/* - in the end all we're doing is implementing a single POST /api/traces endpoint and converting from Zipkin model to Jaeger. The endpoint implementation does not require go-openapi mechanics, the only thing that's needed is generating the data model from zipkin swagger file, which can be done offline.

cc @pavolloffay

[pavolloffay]

What if we moved all Zipkin-related code into another repository and have people run it as a sidecar instead of being part of the main Jaeger collector?

What do you mean exactly? Have a separate zipkin-collector importing jaeger?

IIRC openapi dependencies are used to generate and validate the model.

[jpkrohling]

What if we moved all Zipkin-related code into another repository and have people run it as a sidecar instead of being part of the main Jaeger collector?

Interesting idea. This is actually how NATS export their Prometheus metrics: they have a sidecar that makes the bridge between Prometheus and NATS, translating the internal metrics format into Prometheus'.

Reference: https://github.com/nats-io/prometheus-nats-exporter

[yurishkuro]

What do you mean exactly? Have a separate zipkin-collector importing jaeger?

not collector, a bridge that consumes zipkin formats and forwards to jaeger-collector