Can't re-call SetGlobalTracer with two different types of tracer

[iredelmeier]

This seems to be due to the usage of atomic.Value, which expects to be used with a "consistently typed value".

Running this code:

package main

import (
	"go.opentelemetry.io/api/trace"
	sdktrace "go.opentelemetry.io/sdk/trace"
)

func main() {
	trace.SetGlobalTracer(trace.NoopTracer{})
	sdktrace.Register() // calls trace.SetGlobalTracer()
}

triggers a panic from sync/atomic.

[jmacd]

OTEP 0005 says you can only initialize the global once. If you're testing, please avoid the global instance.

[iredelmeier]

Hmm... Avoiding the global instance completely in testing feels unsustainable. Some examples:

• Testing that plugins use the global if one is not explicitly provided
• Application tests that use a mix of test and real (e.g., SDK) tracers depending on what level they're testing

[jmacd]

I do not believe plugins should use the global tracer.
In fact I think any code that is tested should not use the global tracer.
But if you still believe that tests should be able to replace the tracer instance, my best recommendation is to create a new kind of Tracer instance that can be installed once, that lets you swap in new exporters dynamically, or something like that. I can't imagine a test that wants both real and test-oriented tracers.

Restricting the global to be set only once is a major step in alleviating the concerns of people who dislike globals. It prevents the potential for uncoordinated code to overwrite the global tracer at startup, which could lead to chaos.

[iredelmeier]

@jmacd what do you mean that plugins should not use the global tracer? If anything, I've received pushback against the idea that plugins should permit users to not use global tracers!

We also already use the global tracer in tests, both explicitly (e.g., here and implicitly (e.g., by using the SDK, which can only use the global tracer right now since that's the only publicly exposed mechanism).

For example, adding:

func TestFoo(t *testing.T) {
	trace.SetGlobalTracer(trace.NoopTracer{})
}

anywhere in the propagation_test or the sdk/trace packages will cause all of those tests to fail due to their existing reliance on the global tracer.

[jmacd]

I updated open-telemetry/oteps#45

I expect that plugins would be configured explicitly and installed in the process somehow, and that the application main() function would be the responsible party. I see plugins as different from third-party libraries, which are the intended beneficiaries of the global SDK. I suppose there will be configuration-free plugins that we want to install as an import statement, in which case I propose the use of a test-specific SDK that lets you install exporters dynamically for testing purposes.

[jmacd]

(Even for configuration-free libraries, I would prefer to see the main() function both import the module and call some kind of Init() method on the plugin, passing in the Tracer and/or Meter.)

[iredelmeier]

I updated open-telemetry/oteps#45

I expect that plugins would be configured explicitly and installed in the process somehow, and that the application main() function would be the responsible party. I see plugins as different from third-party libraries, which are the intended beneficiaries of the global SDK. I suppose there will be configuration-free plugins that we want to install as an import statement, in which case I propose the use of a test-specific SDK that lets you install exporters dynamically for testing purposes.

I think the (or at least my!) usage of "plugin" might be part of the confusion here 😅

To clarify, I'm referring to both first- and third-party code.

[hodgesds]

This makes the SDK Tracer practically useless for extending, because the only way to get an instance of it is through the Register function which sets the global.

[rghetia]

Global tracer registry is replaced with global trace provider. This was done in #227. This issue was fixed for provider registry.