Change:
latenciesSummary *metrics.SummaryVec } <del> func newMetricSet(name string, labels []string, helpTemplate string, hasSummary bool) *metricSet { var summary *metrics.SummaryVec if hasSummary { summary = metrics.NewSummaryVec( &metrics.SummaryOpts{ Namespace:      namespace, Subsystem:      subsystem, Name:           fmt.Sprintf("%s_admission_duration_seconds_summary", name), Help:           fmt.Sprintf(helpTemplate, "latency summary in seconds"), MaxAge:         latencySummaryMaxAge, StabilityLevel: metrics.ALPHA, }, labels, ) } return &metricSet{ latencies: metrics.NewHistogramVec( &metrics.HistogramOpts{ Namespace:      namespace, Subsystem:      subsystem, Name:           fmt.Sprintf("%s_admission_duration_seconds", name), Help:           fmt.Sprintf(helpTemplate, "latency histogram in seconds"), Buckets:        latencyBuckets, StabilityLevel: metrics.ALPHA, }, labels, ), latenciesSummary: summary, } } </del> // MustRegister registers all the prometheus metrics in the metricSet. func (m *metricSet) mustRegister() { legacyregistry.MustRegister(m.latencies)

Discussion:
I would like to propose the graduation of the following apiserver metrics from alpha to stable: With the exception of the metric these metrics have been stable for 2 years. The metric has been stable for 12 months.
/sig api-machinery /sig instrumentation
/assign /triage accepted
I'm okay with promoting all of these except I am hesitant about since it is relatively new. Can we omit that one?
I agree with the metric was patched a year ago as part of , so it would be best to wait a bit more until the majority of Kubernetes users catch up to the patched version and start using the new version of the metric in production.
A couple of renaming suggestions, since it is important to get it right before graduation: apiserverresponsesizes =apiserverresponsesizebytes aggregatorunavailableapiservice =aggregatorunavailableapiservices One concern regarding . It was very recently changed but the change was later reverted by In the end, the metric wasn't really changed, but it might raise the concern that some users may still need additional information from this metric so I am on the fence with this one. Side implementation note that we will need to keep in mind if we graduate is that the graduation should only affect the webhook admission metric and not the other, so we will need to pass the stability level to
Thank you and for the feedback. To clarify then, are the decisions to not graduate and final?
I'm actually okay with , the namespace addition was recent but it was a bad idea and was reverted. It has otherwise been in use for quite some time, so I'd be comfortable with promoting it.
I'm willing to make a PR for this one
+1 it wasn't a hard no from my side, just wanted to raise some concerns in case anyone had an objection.
/assign /unassign
Thank you for the feedback, and To summarize, we are in agreement to graduate all but the metric. Please correct me if I'm wrong.
/cc
since all the three metrics that are created with this function are graduating to stable, do you think I should still pass the to the function or should I just set the metrics created by this functions as stable by default? update: Seems like is designed to parse whatever's in front of . So putting a variable there (that is passed to the function) will cause the script to fail. Please correct me if I'm wrong.

update: Even setting the metrics to be stable by default will cause the script to fail and you'll get an error saying for the following line: It appears that the name of the stable metrics should be given to that object as a string and using the output of a function ( in this case) will cause the script to fail.
The PR is ready to be reviewed: