Mark declarative config as stable #4568

jack-berg · 2025-06-24T14:46:10Z

Resolves #4374.

We recently cut a release candidate for opentelemetry-configuration. After some additional bake-in time and review, we'd like to cut a stable release.

The stable release needs to coincide with marking key parts of the specification stable, so I'm opening this PR to solicit feedback such that when the time comes, we can mark the specification and opentelemetry-configuration stable is quick succession.

See open-telemetry/opentelemetry-configuration#100 for status of implementations.

cc @open-telemetry/configuration-maintainers

jack-berg · 2025-06-24T14:46:58Z

This is ready for review, but SHOULD not be merged. Assuming we get the required approvals, I'll coordinate merging this with cutting the corresponding release of opentelemetry-configuration.

github-actions · 2025-07-02T03:35:04Z

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

github-actions · 2025-07-10T03:36:30Z

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

specification/configuration/sdk.md

pellared · 2025-07-10T19:36:24Z

specification/configuration/sdk.md

The type parameter in https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk.md#register-componentprovider is not well-defined.
Is it an enumeration? I guess that the intention is that these are "SDK extension plugin interface" names.

Side note (for sure not needed for stabilization):
Do we want to also add some "instrumentation plugin" which could be any object so that the instrumentation/distribution could parse and interpret after it is returned by https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/api.md#get-instrumentation-config?

Took a crack at it by adding this guidance:

SDKs should represent type in a manner that is idiomatic for their language.
For example, a class literal, an enumeration, or similar.
See supported SDK extension plugins for the set of
supported type values.

Let me know what you think.

It is a lot better. But please create a separate PR for it 😉

PS. I hope you are OK that I made some comments here instead of creating new (spamming) GitHub issues.

Yes the comments are great.

…y-specification into stabilize-declarative-config

jack-berg · 2025-07-10T21:52:33Z

specification/configuration/sdk.md

 whatever manner is idiomatic for the language.

-TODO: Add operation to update SDK components with new configuration for usage
-with OpAmp


Tracking here: #3771

Feel free to resolve.
PS. You can consider adding



if it helps you in future.

jack-berg · 2025-07-10T21:58:29Z

specification/configuration/sdk.md

 fail fast) in accordance with
 initialization [error handling principles](../error-handling.md#basic-error-handling-principles).

-TODO: define behavior if some portion of configuration model is not supported


We now have guidance around misalignment of file_format specified by user and supported by an SDK: https://github.com/open-telemetry/opentelemetry-configuration?tab=readme-ov-file#file-format

Also related, we're working on tooling to allow implementations to document what properties they support here: open-telemetry/opentelemetry-configuration#197

pellared · 2025-07-11T10:31:53Z

specification/configuration/sdk.md

 * [LoggerProvider](../logs/sdk.md#loggerprovider)
 * [Propagators](../context/api-propagators.md#composite-propagator)
-* [ConfigProvider](#configprovider)
+* [ConfigProvider](#configprovider) (**Status**: [Development](../document-status.md))


nit: just to follow the existing pattern from other places of the specification

Suggested change

* [ConfigProvider](#configprovider) (**Status**: [Development](../document-status.md))

* **Status**: [Development](../document-status.md) - [ConfigProvider](#configprovider)

I'm not sure about this. I recently was talking with internal colleagues of mine who were reading the log spec and thought that the a variety of stable components were "In Development" because of confusing placement of the status text. For example:

Because there is no other text in the Logger section, and because its not clear where the "In development" ends, the entire SDK Logger component seems to be unstable, which of course is not the case.

I do think we should be consistent, but think that spec's current strategy for calling out a different status should be improved. Though in this particular case putting the status before the list entry doesn't seem to be more confusing.

Though in this particular case putting the status before the list entry doesn't seem to be more confusing.

I agree therefore I prefer consistency.

that spec's current strategy for calling out a different status should be improved

I also agree but this should be a subject of a separate PR.

I think we could consider making some sections like (using https://github.com/orgs/community/discussions/16925):

Note
Status: Development

Paragraph. Tell me something more.

Not sure how it will render in https://opentelemetry.io/.
@open-telemetry/docs-approvers, do you have any ideas?

For bullet-points, I think that the current strategy may be good enough.

Answering for the @open-telemetry/docs-approvers, it's a known issue that GitHub Markdown alerts don't render well on opentelemetry.io. That being said, there are spec docs that use this notation today.

pellared · 2025-07-11T10:35:18Z

specification/configuration/sdk.md

 * `component_provider` - The `ComponentProvider`.
-* `type` - The type of plugin interface it provides (e.g. SpanExporter, Sampler,
-  etc).
+* `type` - The type of plugin interface it provides.


I do not like that in one place we are saying "component" in other "plugin" or "plugin interfaces".
I know that it keeps the same intention, but it makes me harder to read and interpret the specification.
I propose to use the term "Component" everywhere and just mention in the "Component" definition that this is a plugin that allows extensibility of the Configuration SDK.

That's fine with me. I was trying to connect the dots because elsewhere in the spec we both the words component and plugin interface. I'll try to be consistent here with "component" but also have a callout with something to the effect of: "... (also called plugin interface elsewhere in the spec)"

pellared · 2025-07-11T10:42:11Z

specification/configuration/sdk.md

 * `component_provider` - The `ComponentProvider`.
-* `type` - The type of plugin interface it provides (e.g. SpanExporter, Sampler,
-  etc).
+* `type` - The type of plugin interface it provides.


The https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk.md#supported-sdk-extension-plugins should define "mappings" between a "type" and where it is supposed to be used in the configuration model e.g. that SpanProcessor component is represented in https://github.com/open-telemetry/opentelemetry-configuration/blob/d6b127882f41db92b26017c736a52ceb6f2b4451/schema/tracer_provider.json#L208

Yeah that linking would be helpful 👍

github-actions · 2025-07-19T03:36:50Z

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

github-actions · 2025-07-27T03:47:17Z

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

github-actions · 2025-08-07T03:46:29Z

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

tsloughter · 2025-08-07T19:31:42Z

A concern I have is that this sort of implies that a spec for the behavior of AutoConfiguredOpenTelemetrySdk.initialize().getOpenTelemetrySdk(); is stable, which I think requires that #4591 be done.

Can the spec of config be stable before SDK initialization is defined?

github-actions · 2025-08-15T03:36:10Z

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

github-actions · 2025-08-28T03:25:15Z

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

github-actions · 2025-09-06T03:19:21Z

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

dprotaso · 2025-09-09T18:29:30Z

Is there anything blocking this PR?

github-actions · 2025-09-17T03:19:46Z

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

github-actions · 2025-09-25T03:24:16Z

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

github-actions · 2025-10-03T03:20:00Z

Closed as inactive. Feel free to reopen if this PR is still being worked on.

marcalff · 2025-10-06T08:34:03Z

Re opened.

@jack-berg

Please look at the merge conflict on the spec compliance matrix, due to recent changes to yaml.

github-actions · 2025-10-14T03:24:11Z

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

Mark declarative config as stable

04649ba

jack-berg requested review from a team June 24, 2025 14:46

Merge branch 'main' into stabilize-declarative-config

274afc5

github-actions bot added the Stale label Jul 2, 2025

carlosalberto removed the Stale label Jul 2, 2025

github-actions bot added the Stale label Jul 10, 2025

pellared mentioned this pull request Jul 10, 2025

Add Configuration SDK open-telemetry/opentelemetry-dotnet#6380

Open

pellared reviewed Jul 10, 2025

View reviewed changes

specification/configuration/sdk.md Show resolved Hide resolved

pellared reviewed Jul 10, 2025

View reviewed changes

specification/configuration/sdk.md Show resolved Hide resolved

pellared reviewed Jul 10, 2025

View reviewed changes

jack-berg removed the Stale label Jul 10, 2025

jack-berg added 2 commits July 10, 2025 16:33

Merge branch 'main' of https://github.com/open-telemetry/opentelemetr…

678225d

…y-specification into stabilize-declarative-config

PR feedback

e1a7e09

jack-berg commented Jul 10, 2025

View reviewed changes

pellared reviewed Jul 11, 2025

View reviewed changes

github-actions bot added the Stale label Jul 19, 2025

MrAlias removed the Stale label Jul 19, 2025

github-actions bot added the Stale label Jul 27, 2025

MrAlias removed the Stale label Jul 28, 2025

github-actions bot added the Stale label Aug 7, 2025

MrAlias removed the Stale label Aug 7, 2025

github-actions bot added the Stale label Aug 15, 2025

MrAlias removed the Stale label Aug 15, 2025

Merge branch 'main' into stabilize-declarative-config

72946fb

github-actions bot added the Stale label Aug 28, 2025

carlosalberto removed the Stale label Aug 29, 2025

github-actions bot added the Stale label Sep 6, 2025

lmolkova removed the Stale label Sep 6, 2025

github-actions bot added the Stale label Sep 17, 2025

lmolkova removed the Stale label Sep 18, 2025

github-actions bot added the Stale label Sep 25, 2025

github-actions bot closed this Oct 3, 2025

marcalff reopened this Oct 6, 2025

marcalff requested review from a team as code owners October 6, 2025 08:28

marcalff removed the Stale label Oct 6, 2025

github-actions bot added the Stale label Oct 14, 2025

marcalff removed the Stale label Oct 14, 2025

	* [ConfigProvider](#configprovider) (Status: [Development](../document-status.md))
	* Status: [Development](../document-status.md) - [ConfigProvider](#configprovider)

Mark declarative config as stable #4568

Are you sure you want to change the base?

Mark declarative config as stable #4568

Uh oh!

Conversation

jack-berg commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jack-berg commented Jun 24, 2025

Uh oh!

github-actions bot commented Jul 2, 2025

Uh oh!

github-actions bot commented Jul 10, 2025

Uh oh!

Uh oh!

Uh oh!

pellared Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pellared Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Jul 19, 2025

Uh oh!

github-actions bot commented Jul 27, 2025

Uh oh!

github-actions bot commented Aug 7, 2025

Uh oh!

tsloughter commented Aug 7, 2025

Uh oh!

github-actions bot commented Aug 15, 2025

Uh oh!

github-actions bot commented Aug 28, 2025

Uh oh!

github-actions bot commented Sep 6, 2025

Uh oh!

dprotaso commented Sep 9, 2025

Uh oh!

github-actions bot commented Sep 17, 2025

Uh oh!

github-actions bot commented Sep 25, 2025

Uh oh!

github-actions bot commented Oct 3, 2025

Uh oh!

marcalff commented Oct 6, 2025

Uh oh!

github-actions bot commented Oct 14, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

jack-berg commented Jun 24, 2025 •

edited

Loading

pellared Jul 10, 2025 •

edited

Loading

pellared Jul 30, 2025 •

edited

Loading