Remove the current otel code from the v1 branch

[jpkrohling]

I think it's clear by now that we'll have the v2 entirely built on top of OpenTelemetry Collector in a way that is different than what was initially envisioned. As such, I'd suggest removing the experimental code that we have under cmd/opentelemetry. Benefits:

• simplifies our CI
• simplifies the downstream dependencies (operator, for instance)
• sends a signal to the community the previous assumptions aren't valid anymore, like CLI flag compatibility

[yurishkuro]

Is there parity in v2 with what's in cmd/otel? There is a lot of code there, all the exporters. Are they copied into v2?

[jpkrohling]

I think we should follow the same pattern as upstream otelcol, in that each component is a standalone go module. Shouldn't be that hard to move, right?

[yurishkuro]

1. Personally I'm not a big fan of multiple modules, they complicate development somewhat. If we do them, it might be better not to nest them the way otel is nested inside Jaeger.

2. Can we now consider the building experiment successful and start moving code back into jaeger repo, instead of moving it out?

[jpkrohling]

Multiple modules enable us to use the builder to create custom distributions. We could certainly have a single module with all exporters, but then we'd have to have our own glue code. Agree that we should give some thought to the code organization.

To consider the experiment successful, I would like to build at least one extension that exposes an HTTP port, so that we are sure that the UI/Query can be part of the same binary using the standard tools we are having. If they are extensions on their own go modules, building the all-in-one is really just a matter of having a different manifest.

[joe-elliott]

After some brief experimentation we do appear to need a go.mod in the root of every exporter/receiver/extension that we want to include in the otelcol-builder. I think the primary issue with the existing setup is that the ./cmd/opentelemetry/go.mod file references the outer project. If we organized our go.mod's with one root that referenced the various exporters/processors/receivers I think it would be cleaner.

Something like this?
https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/go.mod

[jpkrohling]

If we organized our go.mod's with one root that referenced the various exporters/processors/receivers I think it would be cleaner.

That's what we discussed during the last community call, from what I remember. Note that we might want to do some experiments before committing, as Bogdan mentioned yesterday during the OpenTelemetry Collector SIG call that they do have some issues around bumping versions and tagging: a module at, say, pkg/somelib would need to be released before their consumers from the same repository, as tagging is per git repo, not Go module.

[jpkrohling]

We are now in a situation where our dependency on the OpenTelemetry Collector is preventing us from bumping our Thrift version:

# go.opentelemetry.io/collector/receiver/zipkinreceiver
/home/jpkroehling/go/pkg/mod/go.opentelemetry.io/collector@v0.16.0/receiver/zipkinreceiver/trace_receiver.go:139:41: not enough arguments in call to transport.ReadListBegin
	have ()
	want (context.Context)
/home/jpkroehling/go/pkg/mod/go.opentelemetry.io/collector@v0.16.0/receiver/zipkinreceiver/trace_receiver.go:149:19: not enough arguments in call to zs.Read
	have (*thrift.TBinaryProtocol)
	want (context.Context, thrift.TProtocol)
# go.opentelemetry.io/collector/receiver/kafkareceiver
/home/jpkroehling/go/pkg/mod/go.opentelemetry.io/collector@v0.16.0/receiver/kafkareceiver/zipkin_unmarshaller.go:90:41: not enough arguments in call to transport.ReadListBegin
	have ()
	want (context.Context)
/home/jpkroehling/go/pkg/mod/go.opentelemetry.io/collector@v0.16.0/receiver/kafkareceiver/zipkin_unmarshaller.go:100:19: not enough arguments in call to zs.Read
	have (*thrift.TBinaryProtocol)
	want (context.Context, thrift.TProtocol)
FAIL	github.com/jaegertracing/jaeger/cmd/opentelemetry/app/defaultcomponents [build failed]
FAIL	github.com/jaegertracing/jaeger/cmd/opentelemetry/app/defaultconfig [build failed]

Funnily enough, we can't release a fix for the Jaeger Agent until Zipkin decides to bump their Thrift version first ;-)