Migrate proto-gen/thrift-gen to jaeger-idl

[yurishkuro]

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 folder proto-gen/model/ (compared to our standard model/) in #6493, then the unit test that tries to use both models fails

panic: proto: duplicate enum registered: jaeger.api_v2.ValueType

goroutine 1 [running]:
github.com/gogo/protobuf/proto.RegisterEnum(...)
        /Users/ysh/golang/pkg/mod/github.com/gogo/[email protected]/proto/properties.go:520
github.com/jaegertracing/jaeger/proto-gen/model.init.0()
        /Users/ysh/dev/jaegertracing/jaeger/proto-gen/model/model.pb.go:713 +0x41c
FAIL    github.com/jaegertracing/jaeger/proto-gen/model 0.452s

As 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 use otel.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:

• reproduce the build steps used in Jaeger to generate proto code in the jaeger-idl repo
• commit Go code in jaeger-idl repo
• Upgrade Jaeger to use generated Go code from jaeger-idl as a dependency
  • Delete proto-gen
  • Clean up Makefile.Proto.mk
  • Delete thrift-gen
  • Clean up Makefile.Thrift.mk
• Upgrade OTEL Contrib to also use types from jaeger-idl instead of from Jaeger

[won-js]

I'll give this issue a try, though it looks a bit challenging for me. However, if someone else wants to work on it, feel free to take it

[danish9039]

working on it !

I'll give this issue a try, though it looks a bit challenging for me. However, if someone else wants to work on it, feel free to take it

currently working on this

[adityachopra29]

Seems like it is taking some time. Also trying this issue.

[Nabil-Salah]

hello @yurishkuro

i was trying to update the main Jaeger repo to use models from jaeger-idl

my approach suggestion is that I can divide it on multiple 2 prs so it can be easy to review and migrate

first I think we can start by

• Upgrade OTEL Contrib to use types from jaeger-idl -> this will ease jaeger transition

then

• we can change jaeger to use jaeger-idl it will be easy as it only needs to change jaeger packages and proto files

if you think I'm good to go I can start

[yurishkuro]

@Nabil-Salah I think you have to start with jaeger repo. Because OTEL imports some of the Jaeger code directly, and that code beings the jaeger/model dependencies, while some other code in OTEL might be using jaeger/model dependencies directly. For example, OTEL depends on code from jaeger/cmd/agent, which is using jaeger/model.

Some modules in OTEL might be upgraded independently, but then you may run into a different issue where the same GRPC type is registered twice, and it will not work. Other OTEL modules would definitely not work if you try to upgrade them first.

Having said that, the same, in theory, could happen if we try to upgrade Jaeger first. But I would start there and see what issues we get into. In the worse case we may have to resort to blanket copying of code (temporarily) to break circular dependency, in particular model<>otlp translation from OTEL.

TLDR - need to try it.

[Nabil-Salah]

okay will take some investigation time and till you what errors encountered or blocking states I reach
in PRs and will move to jaeger-idl models incrementally in jaeger repo.

[yurishkuro]

@Nabil-Salah I already added dependency on jaeger-idl to the main repo. The change you should make is search/replace the imports of jaeger/model and api_v2 with the equivalent paths from jaeger-idl. And then just see what compiles / builds / CI.

[Nabil-Salah]

I tried multiple of things but it always end up with a domino effect

• I pick some module and edit it -> I go out trying to fix other modules that depends on it ending with a block state[1]
• I replace all modules and fix the need of otelids -> I end up with a block state[1]

the two block states are the same

these two files use OTEL what I suggest is that I implement a function that will translate jaeger model Batch from/to jaeger-idl Batch model

it will a cumbersome function but it will be a temporary work until OTEL change

also

• this will lower the time of code review as it will not be of much a change as it will be just search/replace the imports of jaeger/model and api_v2
• will make it easy when the OTEL change happens

[yurishkuro]

what I suggest is that I implement a function that will translate jaeger model Batch from/to jaeger-idl Batch model

I don't think this is a good approach. It is inefficient and still keeps the internal dependency on the model/. Instead, I would copy jaegerTranslator code somewhere jaeger/internal and change it to use jaeger-idl model. Then once we release new version of Jaeger no longer using model/, the OTEL will have to do a similar switch to jaeger-idl. Then once they release and we pick it up, we can delete our copy of jaegerTranslator and go back to official OTEL's version.

[yurishkuro]

copy jaegerTranslator and change it to use jaeger-idl mode

this can be a standalone PR, will not affect anything. Put it into internal/jptrace/translator.

[Nabil-Salah]

okay this looks really good idea
will try it