Merge pull request kubernetes#4415 from danwinship/kep-3705-to-ga

KEP-3705: CloudDualStackNodeIPs to GA

Author: k8s-ci-robot

keps/prod-readiness/sig-network/3705.yaml

@@ -6,3 +6,5 @@ alpha:
   approver: "wojtek-t"
 beta:
   approver: "wojtek-t"
+stable:
+  approver: "wojtek-t"

keps/sig-network/3705-cloud-node-ips/README.md

@@ -259,17 +259,6 @@ values means that the IPv4 `ExternalIP` will be preserved.
 
 ### Test Plan
 
-<!--
-**Note:** *Not required until targeted at a release.*
-The goal is to ensure that we don't accept enhancements with inadequate testing.
-
-All code is expected to have adequate tests (eventually with coverage
-expectations). Please adhere to the [Kubernetes testing guidelines][testing-guidelines]
-when drafting this test plan.
-
-[testing-guidelines]: https://git.k8s.io/community/contributors/devel/sig-testing/testing.md
--->
-
 [X] I/we understand the owners of the involved components may require updates to
 existing tests to make this code solid enough prior to committing the changes necessary
 to implement this enhancement.
@@ -395,10 +384,6 @@ value to a new single-stack value.
 
 ### Rollout, Upgrade and Rollback Planning
 
-<!--
-This section must be completed when targeting beta to a release.
--->
-
 ###### How can a rollout or rollback fail? Can it impact already running workloads?
 
 Assuming no drastic bugs (eg, the cloud provider assigns Node X's IP
@@ -435,21 +420,32 @@ correctly.
 
 ###### Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?
 
-TODO; do a manual test
+Not really applicable. Enable->disable->enable was tested and works
+fine, but:
+
+  - "(feature is disabled) → upgrade → rollback" is uninteresting
+    since the feature is disabled
+
+  - "enable feature → upgrade" is impossible because you can't
+    enable the feature before upgrading to a release that supports it.
+
+  - "upgrade → enable feature → rollback" is expected to fail, because
+    the rolled-back-to kubelet will not support the configuration
+    with the feature enabled.
+
+  - "upgrade → enable feature → disable feature → rollback" is just a
+    combination of the (tested) enable→disable case with the
+    (uninteresting) upgrade→rollback case.
+
+(The question seems more targeted at API objects rather than component
+configuration.)
 
 ###### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.?
 
 No.
 
 ### Monitoring Requirements
 
-<!--
-This section must be completed when targeting beta to a release.
-
-For GA, this section is required: approvers should be able to confirm the
-previous answers based on experience in the field.
--->
-
 ###### How can an operator determine if the feature is in use by workloads?
 
 The operator is the one who would be using the feature (and they can
@@ -479,10 +475,6 @@ No
 
 ### Dependencies
 
-<!--
-This section must be completed when targeting beta to a release.
--->
-
 ###### Does this feature depend on any specific services running in the cluster?
 
 The feature depends on kubelet/cloud provider communication, but it is
@@ -523,17 +515,6 @@ No
 
 ### Troubleshooting
 
-<!--
-This section must be completed when targeting beta to a release.
-
-For GA, this section is required: approvers should be able to confirm the
-previous answers based on experience in the field.
-
-The Troubleshooting section currently serves the `Playbook` role. We may consider
-splitting it into a dedicated `Playbook` document (potentially with some monitoring
-details). For now, we leave it here.
--->
-
 ###### How does this feature react if the API server and/or etcd is unavailable?
 
 It does not add any new failure modes. (The kubelet and cloud provider
@@ -543,19 +524,6 @@ but they _already_ do that. And the failure mode there is just
 
 ###### What are other known failure modes?
 
-<!--
-For each of them, fill in the following information by copying the below template:
-  - [Failure mode brief description]
-    - Detection: How can it be detected via metrics? Stated another way:
-      how can an operator troubleshoot without logging into a master or worker node?
-    - Mitigations: What can be done to stop the bleeding, especially for already
-      running user workloads?
-    - Diagnostics: What are the useful log messages and their required logging
-      levels that could help debug the issue?
-      Not required until feature graduated to beta.
-    - Testing: Are there any tests for failure mode? If not, describe why.
--->
-
 ###### What steps should be taken if SLOs are not being met to determine the problem?
 
 N/A: there are no SLOs.

keps/sig-network/3705-cloud-node-ips/kep.yaml

@@ -6,7 +6,7 @@ owning-sig: sig-network
 participating-sigs:
   - sig-node
   - sig-cloud-provider
-status: implementable
+status: implemented
 creation-date: 2022-11-29
 reviewers:
   - "@aojea"
@@ -22,12 +22,12 @@ see-also:
   - "https://github.com/kubernetes/enhancements/pull/1665"
 
 # The target maturity stage in the current dev cycle for this KEP.
-stage: beta
+stage: stable
 
 # 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.29"
+latest-milestone: "v1.30"
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone: