[v2] How is tenancy handled / configured? Should it be part of storage config?

[yurishkuro]

This might just need some verification / findings, with code links.

[shashank-priyadarshi]

@yurishkuro can I please take this up?

[yurishkuro]

You can try

[mahadzaryab1]

@yurishkuro do you have any more context on this issue? what are we looking to achieve? what do we want to deliver here?

[yurishkuro]

Here's what I am seeing:

$ rg tenancy cmd/jaeger
cmd/jaeger/internal/extension/jaegerquery/server.go
23:	"github.com/jaegertracing/jaeger/pkg/tenancy"
86:	tm := tenancy.NewManager(&s.config.Tenancy)

Seems query extension is using tenancy properly. But nothing else in v2 does?

Meanwhile, in v1 tenancy has top-level CLI flags:

cmd/query/app/flags.go
73:	Tenancy tenancy.Options `mapstructure:"multi_tenancy"`

cmd/collector/app/flags/flags.go
171:	Tenancy tenancy.Options

Finally, somewhat of a weird thing, grpc storage is the only one that also has tenancy config:

plugin/storage/grpc/config.go
16:	Tenancy                      tenancy.Options `mapstructure:"multi_tenancy"`

So some obvious questions:

• the handlers in v1 collector are utilizing tenancy, but not in v2, how would we do that?
• the grpc storage having dedicated tenancy flags makes no sense, we might need to fix in v1 too
• ultimately tenancy is closely related to storage. In v2 storage management is concentrated in storage extension. Should that be the only place in v2 where tenancy is configurable and then passed around into other components?
• even with above, how would tenancy headers be parsed by the receivers? In case of gRPC receiver the metadata might still be present by the time control and Context reaches the storage exporter (except batching will mess it up), but for HTTP receivers tenancy header will be lost, unless OTEL has special mechanisms to capture it into Context

Stepping back, multi-tenancy may not work in v2 at all without support from OTEL. There is a relevant discussion in this PR open-telemetry/opentelemetry-collector#2495