Remove TracerProvider.ApplyConfig and Config

[MrAlias]

The TracerProvider.ApplyConfig method and related Config are additions to the exposed API that likely are not needed nor ideal. The ApplyConfig method exists to update a TracerProvider's configuration. This is an optional part of the specification:

The TracerProvider MAY provide methods to update the configuration.

meaning that we could remove these items and remain compliant with the specification.

Removing this type and method from the exported API will be a reduction in the API. This will reduce the on-boarding load for new users wondering when they should be configuring the TracerProvider (at creation or after with this method). Additionally, it could reduce the maintenance burden if we decide in the future to add direct Setters for the Config fields to avoid issues similar to the ones identified in #1631 but would still need to support this exported method and type.

Removing these will remove functionality from the TracerProvider API, the user will no longer be able to update a configuration of a TracerProvider after it has been created. There do not seem to be any reasons why we would need to update this configuration after creation so this seems justified. If this functionality needs to be added back in we could likely do so in a way that better serves the intended purpose and one that doesn't leak internal implementation details of how the TracerProvider manages a synchronized configuration.

Proposal

Removing the ApplyConfig method from the TracerProvider will make the configuration of span limits, the default sampler, ID generators, and resource immutable. This means that the config field of the TracerProvider which holds an atomic value of the related Config could be flattened into the fields of a Config directly.

Removing this field and with the merging of #1633 the Config type will be unused. It can be removed when this is done.

[ijsong]

If ApplyConfig is removed, we need a way to fix the invalid configuration or NewTracerProvider needs an error type in its return value.

ApplyConfig seems to guarantee some invariants of config for TracerProvider, for example, SpanLimits.EventCountLimit should be a positive value by the ApplyConfig. If only EventCountLimit field of the SpanLimits is zero or negative value, only other fields except EventCountLimit are applied. It seems not to be natural.

opentelemetry-go/sdk/trace/provider.go

Lines 173 to 185 in 9d3416c

	func (p *TracerProvider) ApplyConfig(cfg Config) {
	p.mu.Lock()
	defer p.mu.Unlock()
	c := *p.config.Load().(*Config)
	if cfg.DefaultSampler != nil {
	c.DefaultSampler = cfg.DefaultSampler
	}
	if cfg.IDGenerator != nil {
	c.IDGenerator = cfg.IDGenerator
	}
	if cfg.SpanLimits.EventCountLimit > 0 {
	c.SpanLimits.EventCountLimit = cfg.SpanLimits.EventCountLimit
	}

By the way, I can't find any rules of range of the SpanLimits.EventCountLimit in the specification. If SpanLimits.EventCountLimit is zero, does not the span allow any events in it?

[seh]

See this discussion from the "otel-go" channel in the "Cloud Native Computing Foundation" Slack workspace for a motivation for using the ApplyConfig method.

In particular, I'd like to be able to use tracing while discovering and collecting more fields for the Resource that the TracerProvider holds. I understand that it's possible that some spans would be published that would lack fields that I'd add to the Resource afterward.

[ijsong]

@seh, Could you use Attributes of Span instead of Resource?
I'm not sure that your use case is aligned with the specification. Some explanation of Resource is in the specification.

A Resource is an immutable representation of the entity producing telemetry as Attributes. For example, a process producing telemetry that is running in a container on Kubernetes has a Pod name, it is in a namespace and possibly is part of a Deployment which also has a name. All three of these attributes can be included in the Resource. Note that there are certain "standard attributes" that have prescribed meanings.
...
When used with distributed tracing, a resource can be associated with the TracerProvider when the TracerProvider is created. That association cannot be changed later. When associated with a TracerProvider, all Spans produced by any Tracer from the provider MUST be associated with this Resource.

[MrAlias]

@seh would a SetResource or MergeResource (or both?) method be preferred as a replacement?

[MrAlias]

@ijsong while resources need to be immutable types, the one associated with the TracerProvider is not required to be static. We are removing the ApplyConfig method so that there are no misconfigurations (a blank field in an applied config will remove an existing value), but I don't see why we cannot replace it with more useful configuration options.

[seh]

would a SetResource or MergeResource (or both?) method be preferred as a replacement?

As noted in the parallel Slack discussion, a MergeResource-style function would satisfy my needs. I'm looking only to augment the Resource used to initialize the TracerProvider, adding values that weren't yet available to me at that earlier initialization time.

[ijsong]

Although I could misunderstand the specification, my understanding of it is like these:

1. TracerProvider has configuration such as SpanProcessors, IdGenerator, SpanLimits, and Sampler.
2. The configurations of TracerProvider may be mutable.
3. Resource represents things that produce telemetry.
4. Resource is immutable.
5. Association between TracerProvider and Resource can't be changed.
6. Having multiple TracerProvider is possible.

For 1,

Configuration (i.e., SpanProcessors, IdGenerator, SpanLimits and Sampler) MUST be managed solely by the TracerProvider and it MUST provide some way to configure all of them that are implemented in the SDK, at least when creating or initializing it.

For 2,

The TracerProvider MAY provide methods to update the configuration.

For 3 and 4,

A Resource is an immutable representation of the entity producing telemetry as Attributes.

For 5,

When used with distributed tracing, a resource can be associated with the TracerProvider when the TracerProvider is created. That association cannot be changed later.

For 6,

Thus, implementations of TracerProvider SHOULD allow creating an arbitrary number of TracerProvider instances.

According to these, creating a new TracerProvider with merging Resource seems to be a possible solution.

[ijsong]

Those seem to be related:

• Adding resource attributes post-creation (e.g. via auto-discovery) opentelemetry-specification#1298
• Clarify that resources are immutable opentelemetry-specification#515 (comment)

[ijsong]

@MrAlias @seh
As @seh mentioned in the slack channel (https://cloud-native.slack.com/archives/C01NPAXACKT/p1615856400041700?thread_ts=1615512000.030100&cid=C01NPAXACKT), dynamic augmenting Resource seems to be difficult. But there is another way to augment attributes.

[MrAlias]

When used with distributed tracing, a resource can be associated with the TracerProvider when the TracerProvider is created. That association cannot be changed later.

Yikes, 😬, that is not a normative requirement in the specification yet it seems it is commonly being interpreted as such. That's not great.

Based on the ambiguity, I agree we should take the conservative approach here and try and honor the possible interpretation that the author was trying to make a normative requirement here.