promote size memory backed volumes to stable

Author: kannon92

keps/prod-readiness/sig-node/1967.yaml

@@ -1,3 +1,5 @@
 kep-number: 1967
 beta:
+  approver: "@johnbelamaric"
+stable:
   approver: "@johnbelamaric"

keps/sig-node/1967-size-memory-backed-volumes/README.md

@@ -35,10 +35,14 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
 - [x] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)
 - [x] (R) KEP approvers have approved the KEP status as `implementable`
 - [x] (R) Design details are appropriately documented
-- [x] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input
+- [x] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors)
+  - [x] e2e Tests for all Beta API Operations (endpoints)
+  - [x] (R) Ensure GA e2e tests meet requirements for [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md)
+  - [x] (R) Minimum Two Week Window for GA e2e tests to prove flake free
 - [x] (R) Graduation criteria is in place
+  - [x] (R) [all GA Endpoints](https://github.com/kubernetes/community/pull/1806) must be hit by [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) 
 - [x] (R) Production readiness review completed
-- [x] Production readiness review approved
+- [x] (R) Production readiness review approved
 - [x] "Implementation History" section is up-to-date for milestone
 - [x] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]
 - [x] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes
@@ -141,115 +145,141 @@ potentially inaccurate volume size based on node configuration.
 
 ### Feature Enablement and Rollback
 
-_This section must be completed when targeting alpha to a release._
+#### How can this feature be enabled / disabled in a live cluster?
 
-* **How can this feature be enabled / disabled in a live cluster?**
-  - [x] Feature gate (also fill in values in `kep.yaml`)
-    - Feature gate name: SizeMemoryBackedVolumes
-    - Components depending on the feature gate: kubelet
-    - Will enabling / disabling the feature require downtime or reprovisioning
-      of a node? No
+- [x] Feature gate (also fill in values in `kep.yaml`)
+  - Feature gate name: SizeMemoryBackedVolumes
+  - Components depending on the feature gate: kubelet
+  - Will enabling / disabling the feature require downtime or reprovisioning
+    of a node? No
+
+#### Does enabling the feature change any default behavior?
 
-* **Does enabling the feature change any default behavior?**
 Yes, the kubelet will size the empty dir volume to match the precise
 amount of memory the pod is able to write rather than over or undersizing.
 Prior behavior is node dependent, and so pod authors had no mechanism
 to control this behavior properly.
 
-* **Can the feature be disabled once it has been enabled (i.e. can we roll back
-  the enablement)?** Yes
+#### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement?
+
+Yes
+
+#### What happens if we reenable the feature if it was previously rolled back?
 
-* **What happens if we reenable the feature if it was previously rolled back?**
 Pods that run on that node will have memory backed volumes sized based on Linux
 host default.  The sizing may not align with actual available memory for an app.
 
-* **Are there any tests for feature enablement/disablement?**
+#### Are there any tests for feature enablement/disablement?
+
 No, testing behavior with the feature disabled is dependent on node operating
 system configuration.  The point of this KEP is to address that coupling.
 
 ### Rollout, Upgrade and Rollback Planning
 
-* **How can a rollout fail? Can it impact already running workloads?**
+#### How can a rollout fail? Can it impact already running workloads?
+
 If a pod has more allocatable memory than the default node instance behavior
 of taking 50% node instance memory for sizing emptyDir, a pod could potentially
 write more content to the empty dir volume than previously.  This should have
 no impact on rollout of the cluster or workload.  In practice, applications
 that did exhaust the size of the memory backed volume were not portable across
 instance types or would have had to handle running out of room in that volume.
 
-* **What specific metrics should inform a rollback?**
+#### What specific metrics should inform a rollback?
+
 None.
 
-* **Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?**
+#### Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?
+
 I do not believe this is applicable.
 
-* **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.
+#### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.?
+
 No.
 
 ### Monitoring Requirements
 
-* **How can an operator determine if the feature is in use by workloads?**
+#### How can an operator determine if the feature is in use by workloads?
+
 An operator can audit for pods whose emptyDir medium is memory and a size limit
 is specified.  It's not clear there is a benefit to track this because it only
 impacts how the kubelet better enforces an existing API.
 
-* **What are the SLIs (Service Level Indicators) an operator can use to determine 
-the health of the service?**
+#### What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?
+
 This does not seem relevant to this feature.
 
-* **What are the reasonable SLOs (Service Level Objectives) for the above SLIs?**
+#### How can someone using this feature know that it is working for their instance?
+
+- [x] Other
+  - Details: An operator can audit for pods whose emptyDir medium is     memory and a size limit
+  is specified.
+
+#### What are the reasonable SLOs (Service Level Objectives) for the above SLIs?
+
 This does not seem relevant to this feature.
 
-* **Are there any missing metrics that would be useful to have to improve observability 
-of this feature?**
+#### Are there any missing metrics that would be useful to have to improve observability of this feature?
+
 No.
 
 ### Dependencies
 
-* **Does this feature depend on any specific services running in the cluster?**
+#### Does this feature depend on any specific services running in the cluster?
+
 No
 
 ### Scalability
 
-* **Will enabling / using this feature result in any new API calls?**
+#### Will enabling / using this feature result in any new API calls?
+
 No.
 
-* **Will enabling / using this feature result in introducing new API types?**
+#### Will enabling / using this feature result in introducing new API types?
+
+No
+
+#### Will enabling / using this feature result in any new calls to the cloud?
+
+provider?
+
 No
 
-* **Will enabling / using this feature result in any new calls to the cloud 
-provider?**
+#### Will enabling / using this feature result in increasing size or count of the existing API objects?
+
 No
 
-* **Will enabling / using this feature result in increasing size or count of 
-the existing API objects?**
+#### Will enabling / using this feature result in increasing time taken by any operations covered by [existing SLIs/SLOs]?
+
 No
 
-* **Will enabling / using this feature result in increasing time taken by any 
-operations covered by [existing SLIs/SLOs]?**
+#### Will enabling / using this feature result in non-negligible increase of resource usage (CPU, RAM, disk, IO, ...) in any components?
+
 No
 
-* **Will enabling / using this feature result in non-negligible increase of 
-resource usage (CPU, RAM, disk, IO, ...) in any components?**
+#### Can enabling / using this feature result in resource exhaustion of some node resources (PIDs, sockets, inodes, etc.)?
+
 No
 
 ### Troubleshooting
 
-* **How does this feature react if the API server and/or etcd is unavailable?**
+#### How does this feature react if the API server and/or etcd is unavailable?
+
 No impact.
 
-* **What are other known failure modes?**
+#### What are other known failure modes?
+
 Not applicable.
 
-* **What steps should be taken if SLOs are not being met to determine the problem?**
+#### What steps should be taken if SLOs are not being met to determine the problem?
+
 Not applicable
 
 ## Implementation History
 
 v1.20: Launched to `Alpha`
 v1.22: Moved to `Beta`
+v1.32: Moved to `Stable`
 
 ## Drawbacks
 

keps/sig-node/1967-size-memory-backed-volumes/kep.yaml

@@ -2,6 +2,7 @@ title: Size memory backed volumes
 kep-number: 1967
 authors:
   - "@derekwaynecarr"
+  - "@kannon92" #for stable promotion
 owning-sig: sig-node
 participating-sigs:
   - sig-storage
@@ -20,13 +21,13 @@ stage: beta
 # The most recent milestone for which work toward delivery of this KEP has been
 # done. This can be the current (upcoming) milestone, if it is being actively
 # worked on.
-latest-milestone: "v1.22"
+latest-milestone: "v1.32"
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone:
   alpha: "v1.20"
   beta: "v1.22"
-  stable: "v1.23"
+  stable: "v1.32"
 
 # The following PRR answers are required at alpha release
 # List the feature gate name and the components for which it must be enabled