Merge pull request #4518 from deads2k/paperwork-will-be-the-death-of-me

KEP 4346: Correct sig in kep.yaml

Author: k8s-ci-robot

keps/sig-api-machinery/4346-informer-metrics/README.md

@@ -99,6 +99,9 @@ tags, and then generate with `hack/update-toc.sh`.
       - [Integration tests](#integration-tests)
       - [e2e tests](#e2e-tests)
   - [Graduation Criteria](#graduation-criteria)
+    - [Alpha](#alpha)
+    - [Beta](#beta)
+    - [GA](#ga)
   - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)
   - [Version Skew Strategy](#version-skew-strategy)
 - [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)
@@ -428,6 +431,9 @@ extending the production code to implement this enhancement.
 
 - `<package>`: `<date>` - `<test coverage>`
 
+- Unit tests to ensure that the metrics output meets expectations.
+- Unit tests to ensure that the metrics deletion is functioning properly.
+
 ##### Integration tests
 
 <!--
@@ -529,6 +535,21 @@ in back-to-back releases.
 - Deprecate the flag
 -->
 
+#### Alpha
+
+- Feature implemented behind a feature gate flag
+- Add related integration and unit tests to ensure functionality and make sure there is no memory leak in 
+existing behavior
+
+#### Beta
+
+- Gather feedback from developers and surveys
+- Work on feedback and add additional tests as needed
+
+#### GA
+
+- Decision on GA will be made based on beta feedback
+
 ### Upgrade / Downgrade Strategy
 
 <!--
@@ -543,6 +564,8 @@ enhancement:
   cluster required to make on upgrade, in order to make use of the enhancement?
 -->
 
+N/A
+
 ### Version Skew Strategy
 
 <!--
@@ -602,16 +625,10 @@ well as the [existing list] of feature gates.
 [existing list]: https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/
 -->
 
-- [ ] Feature gate (also fill in values in `kep.yaml`)
+- [X] Feature gate (also fill in values in `kep.yaml`)
   - Feature gate name: InformerMetrics
   - Components depending on the feature gate: 
     - components via client-go library
-- [ ] Other
-  - Describe the mechanism:
-  - Will enabling / disabling the feature require downtime of the control
-    plane?
-  - Will enabling / disabling the feature require downtime or reprovisioning
-    of a node?
 
 ###### Does enabling the feature change any default behavior?
 
@@ -655,7 +672,7 @@ You can take a look at one potential example of such test in:
 https://github.com/kubernetes/kubernetes/pull/97058/files#diff-7826f7adbc1996a05ab52e3f5f02429e94b68ce6bce0dc534d1be636154fded3R246-R282
 -->
 
-For now, there is no tests for feature enablement/disablement. The unit tests will be added.
+For now, there is no tests for feature enablement/disablement. The unit / integration tests will be added.
 
 ### Rollout, Upgrade and Rollback Planning
 
@@ -675,13 +692,17 @@ rollout. Similarly, consider large clusters and how enablement/disablement
 will rollout across nodes.
 -->
 
+Feature has no impact on rollout/rollback, and no impact on running workloads.
+
 ###### What specific metrics should inform a rollback?
 
 <!--
 What signals should users be paying attention to when the feature is young
 that might indicate a serious problem?
 -->
 
+The memory used by this metrics continues to grow, consuming a significant amount
+
 ###### Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?
 
 <!--
@@ -690,12 +711,16 @@ Longer term, we may want to require automated upgrade/rollback tests, but we
 are missing a bunch of machinery and tooling and can't do that now.
 -->
 
+Not yet. In the alpha releases, we could test this.
+
 ###### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.?
 
 <!--
 Even if applying deprecation policies, they may still surprise some users.
 -->
 
+This feature does not deprecate or remove any features/APIs/fields/flags/etc.
+
 ### Monitoring Requirements
 
 <!--
@@ -713,6 +738,8 @@ checking if there are objects with field X set) may be a last resort. Avoid
 logs or events for this purpose.
 -->
 
+- [x] Informer / Reflector (e.g., `lists_total`, `watches_total`) metrics returned by the operator are populated
+
 ###### How can someone using this feature know that it is working for their instance?
 
 <!--
@@ -724,13 +751,13 @@ and operation of this feature.
 Recall that end users cannot usually observe component logs or access metrics.
 -->
 
-- [ ] Events
-  - Event Reason: 
-- [ ] API .status
-  - Condition name: 
-  - Other field: 
-- [ ] Other (treat as last resort)
+- [X] Other (treat as last resort)
   - Details:
+    - The following metrics are available when `InformerMetrics` is enabled:
+      - lists_total
+      - watches_total
+      - last_resource_version
+      - etc.
 
 ###### What are the reasonable SLOs (Service Level Objectives) for the enhancement?
 
@@ -749,18 +776,19 @@ These goals will help you determine what you need to measure (SLIs) in the next
 question.
 -->
 
+The feature gate will increase memory usage. The memory usage should not continuously grow.
+The informerMetrics / eventHandlerMetrics / reflectorMetrics memory consumption is in a stable state.
+
 ###### What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?
 
 <!--
 Pick one more of these and delete the rest.
 -->
 
-- [ ] Metrics
+- [X] Metrics
   - Metric name: Memory usage
   - [Optional] Aggregation method:
   - Components exposing the metric: Operating System/golang pprof
-- [ ] Other (treat as last resort)
-  - Details:
 
 ###### Are there any missing metrics that would be useful to have to improve observability of this feature?
 
@@ -769,6 +797,8 @@ Describe the metrics themselves and the reasons why they weren't added (e.g., co
 implementation difficulties, etc.).
 -->
 
+Not at the moment.
+
 ### Dependencies
 
 <!--

keps/sig-api-machinery/4346-informer-metrics/kep.yaml

@@ -2,9 +2,9 @@ title: Add Informer Metrics
 kep-number: 4346
 authors:
   - "@chenk008"
-owning-sig: api-machinery
+owning-sig: sig-api-machinery
 participating-sigs: []
-status: provisional
+status: implementable
 creation-date: 2023-11-27
 reviewers:
   - "@deads2k"