Multiple Context objects vs using named context

[toumorokoshi]

I was working through #89, which enabled formatters to directly read and write to context objects. One aspect there is that this requires a standard way to set and get context values within a specific namespace.

There are two examples which use that today: DistributedContextManager and Tracer. Both use the Context object under the hood, and allow the passing of a name to access the specific context.

If a user wants to pair the DistributedContext and Tracer, that would require them to create one of each with the same name. This pattern will have to be applied to every unit test that needs to work with one of these contexts.

Instead, I propose the creation of multiple Context objects. Tracers and DistributedContextManager could consume a context object. This simplifies unit testing and also allows one to have a complete context object that could be passed into propagators.

[toumorokoshi]

@a-feld @reyang wanted to get your thoughts on this one.

[reyang]

I guess Context.with_current_context has already provided the functionality you're looking for?

It'll be helpful to have a concrete code example to explain why we want to do this.

[a-feld]

This probably boils down to having a discussion about being more explicit with what is defined in a context within open telemetry. For instance, I would imagine a context could contain both the current default tracer and the current distributed context. We could define interfaces like opentelemetry.get_current_tracer() that retrieve the tracer from the context. Similarly opentelemetry.get_current_span_context() and opentelemetry.get_current_distributed_context().

If a user wants to pair the DistributedContext and Tracer, that would require them to create one of each with the same name.

I still think there may be a misunderstanding about this. As far as I can tell, DistributedContext is not scoped to a tracer; rather it is part of a context.

DistributedContext will be referenced in metrics so accessing the current DistributedContext shouldn't go through a tracer.

Instead, I propose the creation of multiple Context objects. Tracers and DistributedContextManager could consume a context object.

Shouldn't this be the other way around? There should be 1 context that contains the current DistributedContext and the current tracer (I know this isn't exactly how things are currently defined)?

[toumorokoshi]

I agree some global context container with clear methods is the right approach. See: #123 for a proposal around that.

My personal opinion is a global object that we can instantiate multiple of as needed. for example:

opentelemetry.GLOBAL.get_current_tracer()

# opentelemetry/__init__.py
GLOBAL = create_global()

I think regarding the scope of DistributedContext and SpanContext: it's true they are separate, but I think there is some implicit common scoping by virtue of requests being generally the broadest scope.

I think to refine this I want to start a PR around how OTEL will actually be used and integrated with apps. I think I'd like to leave this issue alone until then.

[Oberon00]

context values within a specific namespace

If a user wants to pair the DistributedContext and Tracer, that would require them to create one of each with the same name.

What's that about naming? Where does it come from? Do you think about open-telemetry/oteps#16? The intent of that PR is (or was at least when I last read it) to allow disabling of individual instrumentations by tracer name. To support this use case, tracers with different names would need to share the same context. E.g., one example there is a tracer named "io.opentelemetry.contrib.mongodb". Of course you'd want a mongodb span to adopt the web request span from the "io.opentelemetry.ext.wsgi.flask" tracer as parent when specifying CURRENT_SPAN.

[Oberon00]

I'm fine with supporting only one current context, at least initially. I don't see any relevant use cases that would use multiple current contexts, and I think that support would make specification, configuration and implementation of OpenTelemetry significantly more complex.

Just to highlight one point where this would increase implementation complexity: Python contextvars doc says:

Important: Context Variables should be created at the top module level and never in closures. Context objects hold strong references to context variables which prevents context variables from being properly garbage collected.

[toumorokoshi]

I believe OTEL66 (Context API) resolves this issue, by defining a specification for context variables.