Remove OTEL/contrib dependency on cmd/collector/app/sampling

[yurishkuro]

Part of #6408, please read that first.

The dependency exists in OTEL/contrib/extension/jaegerremotesampling. It might be relatively easy to break, but need to try it out.

• Copy whichever code is needed from cmd/collector/app/sampling and plugin/sampling/strategyprovider/static to OTEL/contrib.
• Refactor Jaeger code internally so that these modules are hidden under some /internal/ package (discuss options/proposals on this ticket first)

[VaibhavMalik4187]

Hi @yurishkuro, I'm interested in trying this. I'll try to prepare a doc to discuss this in detail.

[ary82]

Hi @yurishkuro, for the first part of this issue, here are my findings:

In OTEL/contrib/extension/jaegerremotesampling,

1. The internal package has the following dependencies:

   • Provider interface from cmd/collector/app/sampling/samplingstrategy
   • GRPCHandler from cmd/collector/app/sampling

2. As for the root package in OTEL/contrib/extension/jaegerremotesampling, it depends on the code from:

   • plugin/sampling/strategyprovider/static/constants.go
   • plugin/sampling/strategyprovider/static/options.go
   • plugin/sampling/strategyprovider/static/providers.go

Also, some of these have a dependency on github.com/jaegertracing/jaeger/proto-gen/api_v2, which I can see in the parent issue #6408 is also marked for moving. For this issue, do we need to resolve this dependency on the copied code or should we add it as is?

[yurishkuro]

@ary82 I would keep the dependency on proto-gen/api_v2 for now, to reduce the scope. Once the other dependencies you mentioned are untangled it would be easier to refactor them to not depend on proto-gen from Jaeger (they can generate the same code internally).

[ary82]

Hi @yurishkuro, I'm still learning jaeger's architecture and the code structure, but here's what I think for the second part of this issue:

• As cmd/collector/app/sampling contains the models, interface and factory for sampling strategy components, as well as the GRPCHandler. The structs in model are used by various storage components too. How about moving them to a new package cmd/jaeger/internal/sampling.

• plugin/sampling/strategyprovider defines the implementations of sampling strategies, namely static and adaptive. We can move these to a package inside cmd/jaeger/internal/extension/remotesampling

What do you think?

[yurishkuro]

I don't think you can move stuff into cmd/jaeger/internal/sampling because it's also being used from cmd/collector and it will not be able to access internal from there.

[ary82]

Took a closer look at the dependencies. Currently, cmd/collector/app/sampling components are being used in:

• cmd/collector
• cmd/jaeger
• storage/samplingstore
• plugin/storage components
• Their implementations, adaptive and static, currently in plugin/sampling/strategyprovider (subject to change as part of this issue)
• pkg/clientcfg

Seeing as they have a lot of components depending upon them, would it make more sense in moving these to the root internal?

As for plugin/sampling/strategyprovider components, they're used by:

• cmd/jaeger
• cmd/collector
• cmd/internal

So I think we might benefit from moving them to cmd/internal. Does this make sense?

[yurishkuro]

all the sampling components are effectively internal services, so I would move them to internal/sampling. Can you propose the sub-structure for that, with explanations what each sub-folder will contain?