Make Configurator and Config SDK features optional

[pellared]

Fixes #4644

What

Make Configurator and Config SDK features optional.

See also #4648 (review)

Why

The Go SIG does not want to implement these features.

We want to implement the declarative configuration using via processors.

We are fine with the proposal given we want to implement this configuration using (internally) LogRecordProcessors. We do not want to add LoggerConfigurator into the Go Logs SDK, because we find it unnecessary as everything should be achievable using LogRecordProcessor. The experience for the end-user should remain the same.

Note that we already have:

Enabled is an operation that a LogRecordProcessor MAY implement

for languages that do not want to support Logger.Enabled via processors.

We also do not want to add TracerConfigurator and MeterConfigurator support and would rather use SpanProcessor and Views instead.

[pellared]

@open-telemetry/go-maintainers, PTAL

[Copilot]

Pull Request Overview

This PR makes SDK Configurator features optional by changing requirements from MUST to SHOULD/MAY, allowing language implementations to choose alternative approaches for declarative configuration.

• Changed TracerProvider, MeterProvider, and LoggerProvider requirements from MUST to SHOULD for computing configs
• Added explicit MAY statements for TracerConfigurator, MeterConfigurator, and LoggerConfigurator support
• Updated CHANGELOG.md to document these changes

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
specification/trace/sdk.md	Makes TracerConfigurator optional and changes TracerProvider requirement from MUST to SHOULD
specification/metrics/sdk.md	Makes MeterConfigurator optional and changes MeterProvider requirement from MUST to SHOULD
specification/logs/sdk.md	Makes LoggerConfigurator optional and changes LoggerProvider requirement from MUST to SHOULD
CHANGELOG.md	Documents the configurator changes as optional features

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Pull Request Overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[jsuereth]

Can we use some other terminology to require that MeterProvider will interact with file configuration, in the case it isn't using MeterConfigurator?

[pellared]

For OTel Go it is this is the other way. File configuration module is bootstrapping the MeterProvider (et al). More: https://pkg.go.dev/go.opentelemetry.io/contrib/otelconf@v0.17.0/v0.3.0#NewSDK

[jsuereth]

We also do not want to add TracerConfigurator and MeterConfigurator support and would rather use SpanProcessor and Views instead.

What would the specification look like for this?

I want to make sure we have a hard requirement to support configuration loading (and eventually dynamic reloading), but we need to understand what that looks like. I'd prefer to have Go SIG provide specification for what they need / how hooks will work for that somewhere in the specification.

[jack-berg]

SpanProcessor cannot accomplish the same behavior as TraceConfigurator: If a SpanProcessor filters spans based on scope the trace will be broken. With TraceConfigurator, when spans with a particular scope are disabled, then traces are complete as would-be children spans are properly associated with the parent, not with the spans of the disabled scope.

[pellared]

What would the specification look like for this?

SpanProcessor cannot accomplish the same behavior as TraceConfigurator: If a SpanProcessor filters spans based on scope the trace will be broken.

I think we should make SpanProccessor and MetricView are also capable of achieving the same functionality. Still, I am not sure if this should block this PR.

eventually dynamic reloading

I'd prefer to have Go SIG provide specification for what they need / how hooks will work for that somewhere in the specification.

This could decrease the performance of the SDK even if the feature is unused because of synchronization. Therefore, this should be an opt-in feature. The processors could offer "dynamic reloading".

[jsuereth]

I think we should make SpanProccessor and MetricView are also capable of achieving the same functionality. Still, I am not sure if this should block this PR.

I think it's hard to approve this PR without evidence of this or updates to the specification for it.

I'd prefer to have Go SIG provide specification for what they need / how hooks will work for that somewhere in the specification.

This could decrease the performance of the SDK even if the feature is unused because of synchronization. Therefore, this should be an opt-in feature. The processors could offer "dynamic reloading".

Agreed, but I'm not suggesting we naively force reloading with architecture as-is. I'm looking at OpenTelemetry JS and their 2.0 SDK. I suspect, with the conflux of Config, Entities, OpAMP (and possibly Profiler), we may want to take some time prototyping new SDK architectures that can meet the demands of these in a performant way. Bumping just the SDK without the API is a trigger we can pull to make that happen.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[dashpole]

@pellared I do think we need some mechanism to filter out spans without breaking traces. If you still want to go this route, I think we would need to propose an alternative way to accomplish it. But if we are doing propose alternative ways to accomplish what the Configurator does, we should probably also just replace it entirely, rather than making it an optional feature.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.