Add Beta and Internal metric stability levels, update deprecation timelines

[richabanker]

Which issue(s) this PR fixes:

Issue #kubernetes/kubernetes#133429

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: richabanker

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• contributors/devel/sig-instrumentation/OWNERS [richabanker]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[richabanker]

cc @dgrisonnet @dashpole

[dashpole]

I don't think we want to include DeprecatedVersion in the beta example?

[richabanker]

We do have it in the STABLE example too below, I guess its to emphasize that a metric can be deprecated irrespective of its level but there's a deprecation policy that will be followed based on the stability level of the metric to ensure the more stable metrics are not deleted suddenly without enough prior notice.

[serathius]

I would create a separate section for deprecation independent to stages.

[dashpole]

Maybe include the number of releases it needs to be deprecated for?

[richabanker]

Done

[dgrisonnet]

the deprecation version normally only has a major and minor version

[richabanker]

Done

[richabanker]

Apologies for the late follow up here.
PTAL whenever possible.

@dashpole @dgrisonnet

[serathius]

Not blocking, but I would suggest extending the documentation (for both contributors and users) to explicitly describe the expectations for metric quality, usefulness, and production experience at each level. Similar to the Kubernetes feature lifecycle, metric levels like Alpha, Beta, and GA should reflect whether a metric has been validated in a real-world production environment.

For me that would be:

• Alpha: New metrics with minimal or no production experience. There is no expectation for users to monitor them yet, as they may belong to Alpha features or haven't yet proven their long-term value. Due to the lack of production feedback, there is a high probability these metrics will change or be removed entirely.
• Beta: Metrics that have been validated in production and deemed useful. While not yet "critical," it is recommended that users begin monitoring them. The expectation is that metrics for GA features and critical metrics for Beta features eventually graduate to this level. While less likely than Alpha, these metrics might still change if they are tightly coupled to internal implementation details..
• GA: Crucial metrics covering core Kubernetes features that are expected to change very rarely, if ever. Users should prioritize monitoring these metrics to understand the fundamental health and performance of their clusters. Owned by SIGs.

[richabanker]

Not blocking, but I would suggest extending the documentation (for both contributors and users) to explicitly describe the expectations for metric quality, usefulness, and production experience at each level. Similar to the Kubernetes feature lifecycle, metric levels like Alpha, Beta, and GA should reflect whether a metric has been validated in a real-world production environment.

For me that would be:

• Alpha: New metrics with minimal or no production experience. There is no expectation for users to monitor them yet, as they may belong to Alpha features or haven't yet proven their long-term value. Due to the lack of production feedback, there is a high probability these metrics will change or be removed entirely.
• Beta: Metrics that have been validated in production and deemed useful. While not yet "critical," it is recommended that users begin monitoring them. The expectation is that metrics for GA features and critical metrics for Beta features eventually graduate to this level. While less likely than Alpha, these metrics might still change if they are tightly coupled to internal implementation details..
• GA: Crucial metrics covering core Kubernetes features that are expected to change very rarely, if ever. Users should prioritize monitoring these metrics to understand the fundamental health and performance of their clusters. Owned by SIGs.

I think thats a great addition. Included your suggestion in description for each level. Thanks!!

[richabanker]

Any more suggestions / comments / concerns for this?