RFC to ensure that unstable components are opt-in only

[mx-psi]

Components are clearly labeled with stability levels, which can be inspected via e.g. logs. However, it is currently too easy for unstable components to be used without realizing that they are unstable.

We want to make it so users have to explicitly think about using unstable components. To that end we discussed a few ideas:

• Make core (or a new distribution) that is focused on a core set of stable components (to be expanded/modified from the current list). Make this the 'official' distribution and make contrib less used
• Introduce a new --min-stability-level=<unknown|unmaintained|development|alpha|beta|stable> CLI flag/config field to the Collector binary (or, possibly, to OCB) that is gradually raised over time and that prevents usage at runtime of components below a minimum stability level. Raising the minimum stability level would have to happen in an informed way via, e.g., the Collector survey results or data from vendors.

This issue tracks the creation of an RFC that defines a holistic vision on how to do this. The final RFC probably would have to mix several of these (since, e.g. a component has per-signal stability levels but we currently cannot add only some signals from a component).

If the RFC talks about a new distribution/a redefined 'core' distribution, it does not need to define what specific components it includes (that can be an independent discussion).

[ChrsMark]

Make core (or a new distribution) that is focused on a core set of stable components (to be expanded/modified from the current list). Make this the 'official' distribution and make contrib less used

That would be great!

Introduce a new --min-stability-level=<unknown|unmaintained|development|alpha|beta|stable> CLI flag/config field to the Collector binary (or, possibly, to OCB)

I see value for having this flag both in the Collector binary but also in OCB. Probably for OCB it can be a configuration setting instead of a runtime flag (making this part of the declarative/version-controled manifests)?

since, e.g. a component has per-signal stability levels but we currently cannot add only some signals from a component

My proposal on this has been that components can be stable with just emitting at least 1 stable signal. This means that the component has stable configuration interface and a set of stable emitted signals, while at the same time new signals can be added with lower stability levels allowing for enhancing the component while not breaking the stable parts. Per signal stability guidelines still need some thinking though: #13910

[mx-psi]

Probably for OCB it can be a configuration setting instead of a runtime flag (making this part of the declarative/version-controled manifests)?

Yeah, I guess something like that makes sense. One problem is that we need to expose the stability information in a way that can be easily consumed by OCB (I am not sure we can/should rely on the metadata.yaml file being included on the module zip)

My #13297 (comment) on this has been that components can be stable with just emitting at least 1 stable signal.

Right, more generally I think it makes sense to consider the component-wide stability as the maximum among the stabilities on each signal.

This means that the component has stable configuration interface and a set of stable emitted signals, while at the same time new signals can be added with lower stability levels allowing for enhancing the component while not breaking the stable parts.

That makes sense to me. We don't have this fully written down on the component stability guidelines, but the very last section (the one about versioning) does mention something in that direction (a component can be marked 1.x if it has at least one stable signal).

Per signal stability guidelines still need some thinking though: #13910

Agreed, will take a look at your comment

[mx-psi]

On the Collector stability meeting yesterday I suggested that we wait until the project-wide OTEP is done on this regard so that the implementation we do is aligned with that.

[mx-psi]

Update: OTEP is out open-telemetry/opentelemetry-specification/pull/4813