Graduate Metrics API to GA

[ameukam]

• One-line PR description:

• Issue link:

• Other comments:

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ameukam
Once this PR has been reviewed and has the lgtm label, please assign logicalhan for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• keps/sig-instrumentation/OWNERS

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

[sftim]

Try keps/sig-instrumentation/api-for-internal-metrics/

We try not to call features "Graduate X to GA";we just call them "X".

[sftim]

Suggested change

	name: Graduate metrics.k8s.io API to GA
	title: Graduate metrics.k8s.io API to GA
	name: API for internal metrics integration
	title: API for internal metrics integration

[ameukam]

"internal metrics" ? What do you mean ?

[sftim]

We can pick a different name; the key thing is to drop "Graduate" from the name of the enhancement.

[BenTheElder]

We've called it "graduate ..." on KEPs that are laying out a new plan to stabilize an API.

E.G.

https://github.com/kubernetes/enhancements/tree/master/keps/sig-autoscaling/2702-graduate-hpa-api-to-GA
https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/19-Graduate-CronJob-to-Stable
https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/2334-graduate-server-side-get-and-partial-objects-to-GA/README.md
https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/2338-graduate-API-gzip-compression-support-to-GA
...

[sftim]

On several of those, I've tried to intervene to fix what I see as problematic KEP naming.

#5208 (comment)

[sftim]

KEP-19 for example is now titled CronJobs (previously ScheduledJobs)

[BenTheElder]

We try not to call features "Graduate X to GA";we just call them "X".

We actually do tend to call "graduate X" when we're plotting how to deal with existing functionality that has failed to graduate previously. There are many examples of htis.

We don't do this when it's a net-new feature.

I actually think it's more clear to note that we're not creating a new metrics API, we're discussing how to stabilize the current one.

Calling this "Metrics API" would be pretty misleading, IMHO. Calling it "API for Internal Metrics" isn't any better, it reads like we're creating a new API.

[ameukam]

how to stabilize the current one.

The API metrics concerned here have been stable for a few years. Are there specific criteria we need to meet ?

[BenTheElder]

The API metrics concerned here have been stable for a few years. Are there specific criteria we need to meet ?

Nothing specific -- I don't know why we haven't GA-ed yet, I mean to the point about framing the KEP, and past, similar KEPs.

[sftim]

We actually do tend to call "graduate X" when we're plotting how to deal with existing functionality that has failed to graduate previously. There are many examples of htis.

Yes, but we shouldn't, because then when you promote it from beta to GA you end up with "Promote Graduate X to Stable
from beta to GA" as a PR title. Or other problems of conflating the graduation with the feature.

[BenTheElder]

Yes, but we shouldn't, because then when you promote it from beta to GA you end up with "Promote Graduate X to Stable
from beta to GA" as a PR title. Or other problems of conflating the graduation with the feature.

We don't have to name the PRs that way.
I disagree, I think it's much clearer to note that the scope of the KEP is stabilizing the feature and the proposed alternatives make it sound like a new API.
Not to mention established conventions are familiar.

But that discussion should probably be taken to sig-architecture. I don't think we should be trying to establish a new pattern by bikeshedding individual KEP issue(s) / PR(s). I haven't seen any prior discussion that we should alter this pattern.

[sftim]

Hmm; the pattern of "name KEP after the enhancement it provides" is IMO well established and documented, even if we don't always follow the pattern.

[sftim]

the proposed alternatives make it sound like a new API.

Ah, here's the thing. I think of the audience, for KEPs, being "Kubernetes end users who want to know what the enhancement is", and maybe @BenTheElder you think of the audience being "Kubernetes contributors" or "subset of Kubernetes contributors".

I'm thinking of what https://www.kubernetes.dev/resources/keps/ should look like.

[sftim]

I'm not proposing that we retrofit existing KEPs. For example, https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/95-custom-resource-definitions/kep.yaml doesn't gain metadata about alpha and beta stages.

Maybe we could do that as well, but that's not what I'm proposing. Just a change to the title of this provisional KEP.

[pohly]

Whatever it's going to be called, please use 5027-<title-with-no-spaces> as directory name.

The way it is now is just odd:

https://github.com/kubernetes/enhancements/tree/d6ee32ff9f5cf7d8f3748518e9d2a8ae58658c01/keps/sig-instrumentation

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[rexagod]

/remove-lifecycle stale
/lifecycle frozen

PRs are up, need reviews.

[k8s-ci-robot]

@rexagod: The lifecycle/frozen label cannot be applied to Pull Requests.

In response to this:

/remove-lifecycle stale
/lifecycle frozen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[rexagod]

@ameukam Are you still working on this?

[ameukam]

@ameukam Are you still working on this?

@rexagod Unfortunately no. Happy to close this if someone else want to give a shot.

[rexagod]

I've opened PRs for custom and external metrics, and happy to do one for this.

Closing this; thank you for your interest and work on this. 🙂

/close

[k8s-ci-robot]

@rexagod: Closed this PR.

In response to this:

I've opened PRs for custom and external metrics, and happy to do one for this.

Closing this; thank you for your interest and work on this. 🙂

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.