Migrate proto-gen/thrift-gen to jaeger-idl #6494
Labels
good first issue
Good for beginners
help wanted
Features that maintainers are willing to accept but do not have cycles to implement
In #6408 it was proposed that we break up the circular dependency between Jaeger and OTEL code bases by cloning some of the code from Jaeger to OTEL, in particular the auto-generated classes for Proto and Thrift.
However, it turns out Proto does not work if the same Protobuf type is registered more than once, because Proto uses a global registry. For example, when I used
model.proto
to generate the output into a different folderproto-gen/model/
(compared to our standardmodel/
) in #6493, then the unit test that tries to use both models failsAs a result, a number of sub-tasks proposed in #6408 will not work if both OTEL and Jaeger have proto-generated types for the same .proto interfaces. This is likely the same issue as reported in open-telemetry/opentelemetry-go-contrib#6555.
One possible workaround is to tweak the IDL files to use a different namespace for the Proto types, e.g. instead of
jaeger.api_v2.ValueType
the OTEL could useotel.jaeger.api_v2.ValueType
. This only works if the generated structs are used to marshal binary payloads like[]byte
where the namespace of the type does not matter. But if an actual Proto service is implemented then I don't think it can use a different namespace, since then the clients won't be able to use that service.Since it does not seem like we'd be able to easily avoid OTEL code using some of the Jaeger proto structs, the proposal is to move them out of Jaeger repository. We already include jaeger-idl as a submodule and read the proto files from there to generate code. Instead, we can use jaeger-idl as a regular Go dependency and generate the code in that repository (we already do that today as part of IDL repo CI, but we don't persist that code).
Tasks:
The text was updated successfully, but these errors were encountered: