From 53669b7ae269894c2c878b3f93c2e7714c7098ae Mon Sep 17 00:00:00 2001
From: Lee Verberne <verb@google.com>
Date: Fri, 10 Jun 2022 17:54:38 +0200
Subject: [PATCH] KEP-277: Target stable in 1.25

---
 keps/prod-readiness/sig-node/277.yaml         |   2 +
 .../277-ephemeral-containers/README.md        | 402 ++++++++++++++----
 .../277-ephemeral-containers/kep.yaml         |   4 +-
 3 files changed, 329 insertions(+), 79 deletions(-)

diff --git a/keps/prod-readiness/sig-node/277.yaml b/keps/prod-readiness/sig-node/277.yaml
index b2db29fd726..1ff2b71a718 100644
--- a/keps/prod-readiness/sig-node/277.yaml
+++ b/keps/prod-readiness/sig-node/277.yaml
@@ -3,3 +3,5 @@ alpha:
   approver: "@johnbelamaric"
 beta:
   approver: "@johnbelamaric"
+stable:
+  approver: "@johnbelamaric"
diff --git a/keps/sig-node/277-ephemeral-containers/README.md b/keps/sig-node/277-ephemeral-containers/README.md
index 026c5cfb2b4..5554e26d876 100644
--- a/keps/sig-node/277-ephemeral-containers/README.md
+++ b/keps/sig-node/277-ephemeral-containers/README.md
@@ -33,6 +33,11 @@
     - [Updating a Pod](#updating-a-pod)
   - [Container Runtime Interface (CRI) changes](#container-runtime-interface-cri-changes)
   - [Test Plan](#test-plan)
+      - [Prerequisite testing updates](#prerequisite-testing-updates)
+      - [Unit tests](#unit-tests)
+      - [Integration tests](#integration-tests)
+      - [e2e tests](#e2e-tests)
+  - [Test Plan](#test-plan-1)
   - [Graduation Criteria](#graduation-criteria)
     - [Alpha -&gt; Beta Graduation](#alpha---beta-graduation)
     - [Beta -&gt; GA Graduation](#beta---ga-graduation)
@@ -631,14 +636,7 @@ updated to support container namespace targeting, described fully in
 
 <!--
 **Note:** *Not required until targeted at a release.*
-
-Consider the following in developing a test plan for this enhancement:
-- Will there be e2e and integration tests, in addition to unit tests?
-- How will it be tested in isolation vs with other components?
-
-No need to outline all of the test cases, just the general strategy. Anything
-that would count as tricky in the implementation, and anything particularly
-challenging to test, should be called out.
+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]
@@ -646,15 +644,77 @@ when drafting this test plan.
 
 [testing-guidelines]: https://git.k8s.io/community/contributors/devel/sig-testing/testing.md
 -->
-This feature will be tested with a combination of unit, integration and e2e
-tests. In particular:
 
-* Field validation (e.g. of Container fields disallowed in Ephemeral Containers)
-  will be tested in unit tests.
-* Pod update semantics will be tested in integration tests.
-* Ephemeral Container creation will be tested in e2e-node.
+[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.
+
+##### Prerequisite testing updates
+
+<!--
+Based on reviewers feedback describe what additional tests need to be added prior
+implementing this enhancement to ensure the enhancements have also solid foundations.
+-->
+
+N/A - This feature was implemented prior to the addition of this section to the KEP
+template.
+
+##### Unit tests
+
+<!--
+In principle every added code should have complete unit test coverage, so providing
+the exact set of tests will not bring additional value.
+However, if complete unit test coverage is not possible, explain the reason of it
+together with explanation why this is acceptable.
+-->
+
+Complete unit test coverage is possible.
+
+<!--
+Additionally, for Alpha try to enumerate the core package you will be touching
+to implement this enhancement and provide the current unit coverage for those
+in the form of:
+- <package>: <date> - <current test coverage>
+The data can be easily read from:
+https://testgrid.k8s.io/sig-testing-canaries#ci-kubernetes-coverage-unit
+
+This can inform certain test coverage improvements that we want to do before
+extending the production code to implement this enhancement.
+-->
+
+This enhancement was implemented prior to test coverage reporting.
 
-None of the tests for this feature are unusual or tricky.
+
+##### Integration tests
+
+<!--
+This question should be filled when targeting a release.
+For Alpha, describe what tests will be added to ensure proper quality of the enhancement.
+
+For Beta and GA, add links to added tests together with links to k8s-triage for those tests:
+https://storage.googleapis.com/k8s-triage/index.html
+-->
+
+- `k8s.io/kubernetes/test/integration/pods/pods_test.go`: https://storage.googleapis.com/k8s-triage/index.html?test=TestPodCreateEphemeralContainers
+- `k8s.io/kubernetes/test/integration/pods/pods_test.go`: https://storage.googleapis.com/k8s-triage/index.html?test=TestPodPatchEphemeralContainers
+- `k8s.io/kubernetes/test/integration/pods/pods_test.go`: https://storage.googleapis.com/k8s-triage/index.html?test=TestPodUpdateEphemeralContainers
+- `k8s.io/kubernetes/test/integration/pods/pods_test.go`: https://storage.googleapis.com/k8s-triage/index.html?test=TestPodEphemeralContainersDisabled
+
+##### e2e tests
+
+<!--
+This question should be filled when targeting a release.
+For Alpha, describe what tests will be added to ensure proper quality of the enhancement.
+
+For Beta and GA, add links to added tests together with links to k8s-triage for those tests:
+https://storage.googleapis.com/k8s-triage/index.html
+
+We expect no non-infra related flakes in the last month as a GA graduation criteria.
+-->
+
+- `k8s.io/kubernetes/test/e2e/common/node/ephemeral_containers.go`: https://storage.googleapis.com/k8s-triage/index.html?test=Ephemeral%20Containers
+
+### Test Plan
 
 ### Graduation Criteria
 
@@ -662,19 +722,19 @@ None of the tests for this feature are unusual or tricky.
 
 - [x] Ephemeral Containers API has been in alpha for at least 2 releases.
 - [x] Ephemeral Containers support namespace targeting.
-- [ ] Metrics for Ephemeral Containers are added to existing contain creation
+- [x] Metrics for Ephemeral Containers are added to existing contain creation
   metrics.
 - [x] CLI using Ephemeral Containers for debugging checked into a Kubernetes
   project repository (e.g. in `kubectl` or a `kubectl` plugin).
 - [x] A task on https://kubernetes.io/docs/tasks/ describes how to troubleshoot
   a running pod using Ephemeral Containers.
-- [ ] Ephemeral Container creation is covered by e2e-node tests.
-- [ ] Update via `/ephemeralcontainers` validates entire PodSpec to protect against future bugs.
+- [x] Ephemeral Container creation is covered by e2e-node tests.
+- [x] Update via `/ephemeralcontainers` validates entire PodSpec to protect against future bugs.
 
 #### Beta -> GA Graduation
 
-- [ ] Ephemeral Containers have been in beta for at least 2 releases.
-- [ ] Ephemeral Containers see use in 3 projects or articles.
+- [x] Ephemeral Containers have been in beta for at least 2 releases.
+- [x] Ephemeral Containers see use in 3 projects or articles.
 - [ ] Ephemeral Container creation is covered by [conformance tests].
 - [ ] The following cosmetic codebase TODOs are resolved:
   - [ ] kubectl incorrectly suggests a debug container can be reattached after exit
@@ -730,34 +790,69 @@ you need any help or guidance.
 
 ### Feature Enablement and Rollback
 
-_This section must be completed when targeting alpha to a release._
+<!--
+This section must be completed when targeting alpha to a release.
+-->
+
+###### How can this feature be enabled / disabled in a live cluster?
+
+<!--
+Pick one of these and delete the rest.
+
+Documentation is available on [feature gate lifecycle] and expectations, as
+well as the [existing list] of feature gates.
+
+[feature gate lifecycle]: https://git.k8s.io/community/contributors/devel/sig-architecture/feature-gates.md
+[existing list]: https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/
+-->
 
-* **How can this feature be enabled / disabled in a live cluster?**
   - [x] Feature gate (also fill in values in `kep.yaml`)
     - Feature gate name: EphemeralContainers
     - Components depending on the feature gate: kube-apiserver, kubelet
-  - [ ] 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? (Do not assume `Dynamic Kubelet Config` feature is enabled).
 
-* **Does enabling the feature change any default behavior?**
+###### Does enabling the feature change any default behavior?
+
+<!--
+Any change of default behavior may be surprising to users or break existing
+automations, so be extremely careful here.
+-->
 
   No, this feature does not change existing behavior.
 
-* **Can the feature be disabled once it has been enabled (i.e. can we roll back
-  the enablement)?**
+###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)?
+
+<!--
+Describe the consequences on existing workloads (e.g., if this is a runtime
+feature, can it break the existing applications?).
+
+Feature gates are typically disabled by setting the flag to `false` and
+restarting the component. No other changes should be necessary to disable the
+feature.
+
+NOTE: Also set `disable-supported` to `true` or `false` in `kep.yaml`.
+-->
 
   Yes. Any running ephemeral containers will continue to run, but they will
   become inaccessible and exit when the Pod is deleted.
 
-* **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?
 
   This behaves as expected: the feature will begin working again.
 
-* **Are there any tests for feature enablement/disablement?**
+###### Are there any tests for feature enablement/disablement?
+
+<!--
+The e2e framework does not currently support enabling or disabling feature
+gates. However, unit tests in each component dealing with managing data, created
+with and without the feature, are necessary. At the very least, think about
+conversion tests if API types are being modified.
+
+Additionally, for features that are introducing a new API field, unit tests that
+are exercising the `switch` of feature gate itself (what happens if I disable a
+feature gate after having objects written with the new field) are also critical.
+You can take a look at one potential example of such test in:
+https://github.com/kubernetes/kubernetes/pull/97058/files#diff-7826f7adbc1996a05ab52e3f5f02429e94b68ce6bce0dc534d1be636154fded3R246-R282
+-->
 
   Some unit tests are exercised with the feature both enabled and disabled to
   verify proper behavior in both cases. Integration test verify that the API
@@ -780,9 +875,21 @@ _This section must be completed when targeting alpha to a release._
 
 ### Rollout, Upgrade and Rollback Planning
 
-_This section must be completed when targeting beta graduation to a release._
+<!--
+This section must be completed when targeting beta to a release.
+-->
+
+###### How can a rollout or rollback fail? Can it impact already running workloads?
+
+<!--
+Try to be as paranoid as possible - e.g., what if some components will restart
+mid-rollout?
 
-* **How can a rollout fail? Can it impact already running workloads?**
+Be sure to consider highly-available clusters, where, for example,
+feature flags will be enabled on some API servers and not others during the
+rollout. Similarly, consider large clusters and how enablement/disablement
+will rollout across nodes.
+-->
 
   This feature allows setting a new field, `ephemeralContainers` in a Pod spec.
   Enabling the feature won't affect existing workloads since they were not
@@ -790,16 +897,24 @@ _This section must be completed when targeting beta graduation to a release._
 
   Component restarts won't affect this feature.
 
-* **What specific metrics should inform a rollback?**
+###### 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?
+-->
 
   A rollback is only indicated if there's a catastrophic failure that prevents
   the cluster from functioning normally, for example if pod or container
   creation begins to fail.
 
-* **Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?**
-  Describe manual testing that was done and the outcomes.
-  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.
+###### Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?
+
+<!--
+Describe manual testing that was done and the outcomes.
+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.
+-->
 
   Since this feature is not critical to production workloads, the main risk
   is that enabling the feature by default will adversely affect other components.
@@ -831,16 +946,30 @@ _This section must be completed when targeting beta graduation to a release._
   ephemeral containers. We'll investigate whether it's possible to add ephemeral
   containers to these existing tests.
 
-* **Is the rollout accompanied by any deprecations and/or removals of features, APIs, 
-fields of API types, flags, etc.?**
+###### 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.
+-->
 
   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.
+-->
 
-_This section must be completed when targeting beta graduation to a release._
 
-* **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?
+
+<!--
+Ideally, this should be a metric. Operations against the Kubernetes API (e.g.,
+checking if there are objects with field X set) may be a last resort. Avoid
+logs or events for this purpose.
+-->
 
   This information is available by examining pod objects in the API server
   for the field `pod.spec.ephemeralContainers`. Additionally, the kubelet surfaces
@@ -855,38 +984,86 @@ _This section must be completed when targeting beta graduation to a release._
     when this kubelet starts containers, idnexed by `container_type`.
     Ephemeral containers have a `container_type` of `ephemeral_container`.
 
-* **What are the SLIs (Service Level Indicators) an operator can use to determine 
-the health of the service?**
+###### How can someone using this feature know that it is working for their instance?
+
+<!--
+For instance, if this is a pod-related feature, it should be possible to determine if the feature is functioning properly
+for each individual pod.
+Pick one more of these and delete the rest.
+Please describe all items visible to end users below with sufficient detail so that they can verify correct enablement
+and operation of this feature.
+Recall that end users cannot usually observe component logs or access metrics.
+-->
+
+- [x] Events
+  - Event Reason: (same as Containers/InitContainers)
+- [x] API .status
+  - Other field: pod.status.ephemeralContainerStatuses[x].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.
+-->
+
   - [x] Metrics
     - Metric name: `apiserver_request_total{component="apiserver",resource="pods",subresource="ephemeralcontainers"}` (apiserver), `kubelet_started_containers_errors_total{container_type="ephemeral_container"}`
     - [Optional] Aggregation method: Aggregate by container type
     - Components exposing the metric: apiserver, kubelet
-  - [ ] Other (treat as last resort)
-    - Details:
 
-* **What are the reasonable SLOs (Service Level Objectives) for the above SLIs?**
-  At a high level, this usually will be in the form of "high percentile of SLI
-  per day <= X". It's impossible to provide comprehensive guidance, but at the very
-  high level (needs more precise definitions) those may be things like:
+###### What are the reasonable SLOs (Service Level Objectives) for the enhancement?
+
+<!--
+This is your opportunity to define what "normal" quality of service looks like
+for a feature.
+
+It's impossible to provide comprehensive guidance, but at the very
+high level (needs more precise definitions) those may be things like:
   - per-day percentage of API calls finishing with 5XX errors <= 1%
   - 99% percentile over day of absolute value from (job creation time minus expected
     job creation time) for cron job <= 10%
-  - 99,9% of /health requests per day finish with 200 code
+  - 99.9% of /health requests per day finish with 200 code
+
+These goals will help you determine what you need to measure (SLIs) in the next
+question.
+-->
 
   Ephemeral containers are, by design, best effort. We are unable to offer an SLO
   for ephemeral containers until the kubelet supports some sort of dynamic resource
   reallocation.
 
-* **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?
+
+<!--
+Describe the metrics themselves and the reasons why they weren't added (e.g., cost,
+implementation difficulties, etc.).
+-->
 
   No.
 
 ### Dependencies
 
-_This section must be completed when targeting beta graduation to a release._
+<!--
+This section must be completed when targeting beta to a release.
+-->
+
+###### Does this feature depend on any specific services running in the cluster?
 
-* **Does this feature depend on any specific services running in the cluster?**
+<!--
+Think about both cluster-level services (e.g. metrics-server) as well
+as node-level agents (e.g. specific version of CRI). Focus on external or
+optional services that are needed. For example, if this feature depends on
+a cloud provider API, or upon an external software-defined storage or network
+control plane.
+
+For each of these, fill in the following—thinking about running existing user workloads
+and creating new ones, as well as about cluster-level services (e.g. DNS):
+  - [Dependency name]
+    - Usage description:
+      - Impact of its outage on the feature:
+      - Impact of its degraded performance or high-error rates on the feature:
+-->
 
   - Runtime support for [Namespace targeting].
     - Usage description: One feature of Ephemeral containers, namespace
@@ -900,20 +1077,42 @@ _This section must be completed when targeting beta graduation to a release._
 
 ### Scalability
 
-_For alpha, this section is encouraged: reviewers should consider these questions
-and attempt to answer them._
+<!--
+For alpha, this section is encouraged: reviewers should consider these questions
+and attempt to answer them.
+
+For beta, this section is required: reviewers must answer these questions.
 
-_For beta, this section is required: reviewers must answer these questions._
+For GA, this section is required: approvers should be able to confirm the
+previous answers based on experience in the field.
+-->
 
-_For GA, this section is required: approvers should be able to confirm the
-previous answers based on experience in the field._
+###### Will enabling / using this feature result in any new API calls?
 
-* **Will enabling / using this feature result in any new API calls?**
+<!--
+Describe them, providing:
+  - API call type (e.g. PATCH pods)
+  - estimated throughput
+  - originating component(s) (e.g. Kubelet, Feature-X-controller)
+Focusing mostly on:
+  - components listing and/or watching resources they didn't before
+  - API calls that may be triggered by changes of some Kubernetes resources
+    (e.g. update of object X triggers new updates of object Y)
+  - periodic API calls to reconcile state (e.g. periodic fetching state,
+    heartbeats, leader election, etc.)
+-->
 
   Not in a meaningful way. Any additional calls would fall within existing
   usage patterns of humans interactive with Pods.
 
-* **Will enabling / using this feature result in introducing new API types?**
+###### Will enabling / using this feature result in introducing new API types?
+
+<!--
+Describe them, providing:
+  - API type
+  - Supported number of objects per cluster
+  - Supported number of objects per namespace (for namespace-scoped objects)
+-->
 
   There an no new Kinds for storage, but new types are used in `v1.Pod`.
   Ephemeral containers are added by writing a `v1.Pod` containing
@@ -925,13 +1124,24 @@ previous answers based on experience in the field._
   - Supported number of objects per cluster: same as Pods
   - Supported number of objects per namespace: same as Pods
 
-* **Will enabling / using this feature result in any new calls to the cloud 
-provider?**
+###### Will enabling / using this feature result in any new calls to the cloud provider?
+
+<!--
+Describe them, providing:
+  - Which API(s):
+  - Estimated increase:
+-->
 
   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 size or count of the existing API objects?
+
+<!--
+Describe them, providing:
+  - API type(s):
+  - Estimated increase in size: (e.g., new annotation of size 32B)
+  - Estimated amount of new objects: (e.g., new Object X for every existing Pod)
+-->
 
   - API type(s): v1.Pod
   - Estimated increase in size: Additional `Container` for each Ephemeral
@@ -939,14 +1149,31 @@ the existing API objects?**
     manually by humans.
   - Estimated amount of new objects: N/A
 
-* **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 increasing time taken by any operations covered by existing SLIs/SLOs?
+
+<!--
+Look at the [existing SLIs/SLOs].
+
+Think about adding additional work or introducing new steps in between
+(e.g. need to do X to start a container), etc. Please describe the details.
+
+[existing SLIs/SLOs]: https://git.k8s.io/community/sig-scalability/slos/slos.md#kubernetes-slisslos
+-->
 
   When users add additional containers to a Pod, the pod will have additional
   containers to shut down and garbage collect when the Pod exits.
 
-* **Will enabling / using this feature result in non-negligible increase of 
-resource usage (CPU, RAM, disk, IO, ...) in any components?**
+###### Will enabling / using this feature result in non-negligible increase of resource usage (CPU, RAM, disk, IO, ...) in any components?
+
+<!--
+Things to keep in mind include: additional in-memory state, additional
+non-trivial computations, excessive access to disks (including increased log
+volume), significant amount of data sent and/or received over network, etc.
+This through this both in small and large cases, again with respect to the
+[supported limits].
+
+[supported limits]: https://git.k8s.io/community//sig-scalability/configs-and-limits/thresholds.md
+-->
 
   Not automatically. Use of this feature will result in additional containers
   running on kubelets, but it does not change the amount of resources allocated
@@ -954,17 +1181,36 @@ resource usage (CPU, RAM, disk, IO, ...) in any components?**
 
 ### 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.
+-->
 
-_This section must be completed when targeting beta graduation to a release._
-
-* **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?
 
   Identical to other (non-ephemeral) containers.
 
-* **What are other known failure modes?**
+###### 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.
+-->
+
   - Addition of ephemeral container is prohibited by API server
     - Detection: API server metric described in monitoring section
     - Mitigations: None. This doesn't affect user workloads.
@@ -991,7 +1237,7 @@ _This section must be completed when targeting beta graduation to a release._
   without a restart by removing authorization to `ephemeralcontainers` subresource
   via [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).
 
-* **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?
 
   Troubleshoot using apiserver and kubelet error logs.
 
@@ -1014,6 +1260,8 @@ _This section must be completed when targeting beta graduation to a release._
 - *2021-05-14*: Add additional graduation criteria
 - *2021-07-09*: Revert KEP to alpha because of the new API introduced in 1.22.
 - *2021-08-23*: Updated KEP for beta release in 1.23.
+- *2022-06-10*: Updated Testing and Production Readiness sections to new format.
+- *2022-06-10*: Updated KEP for stable release in 1.25.
 
 ## Drawbacks
 
diff --git a/keps/sig-node/277-ephemeral-containers/kep.yaml b/keps/sig-node/277-ephemeral-containers/kep.yaml
index 99f61dc145e..76387224869 100644
--- a/keps/sig-node/277-ephemeral-containers/kep.yaml
+++ b/keps/sig-node/277-ephemeral-containers/kep.yaml
@@ -19,12 +19,12 @@ see-also:
   - "/keps/sig-cli/1441-kubectl-debug"
 
 # 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.23"
+latest-milestone: "v1.25"
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone: