-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Add Beta and Internal metric stability levels, update deprecation timelines #8708
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
[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
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| Name: "some_beta_metric", | ||
| Help: "some description", | ||
| StabilityLevel: kubemetrics.BETA, | ||
| DeprecatedVersion: "1.15", // this is a custom metadata field |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want to include DeprecatedVersion in the beta example?
|
|
||
| By the beta stability contract, we mean: | ||
|
|
||
| 1. the metric will not be deleted without graduating to stable first or being deprecated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe include the number of releases it needs to be deprecated for?
| Metrics can be annotated with a Kubernetes version, from which point that metric will be considered deprecated. This allows us to indicate that a metric is slated for future removal and provides the consumer a reasonable window in which they can make changes to their monitoring infrastructure which depends on this metric. | ||
|
|
||
| While deprecation policies only actually change stability guarantees for __stable__ metrics (and not __alpha__ ones), deprecation information may however be optionally provided on alpha metrics to help component owners inform users of future intent, to help with transition plans (this change was made at the request of @dashpole, who helpfully pointed out that it would be nice to be able signal future intent even for alpha metrics). | ||
| While deprecation policies only actually change stability guarantees for __stable__ metrics (and not __alpha__ ones), deprecation information may however be optionally provided on alpha (and beta metrics) to help component owners inform users of future intent, to help with transition plans (this change was made at the request of @dashpole, who helpfully pointed out that it would be nice to be able signal future intent even for alpha/beta metrics). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm honored to be included in our documentation :). But probably it is better to just explain the rationale and drop this change was made at my request.
| While deprecation policies only actually change stability guarantees for __stable__ metrics (and not __alpha__ ones), deprecation information may however be optionally provided on alpha (and beta metrics) to help component owners inform users of future intent, to help with transition plans (this change was made at the request of @dashpole, who helpfully pointed out that it would be nice to be able signal future intent even for alpha/beta metrics). | |
| While a deprecation period is only required for __stable__ metrics, an alpha or beta metric may still be deprecated prior to removal to help component owners inform users of future intent, and to ease the transition to the replacement metrics. |
Which issue(s) this PR fixes:
Issue #kubernetes/kubernetes#133429