Clarify MinReadySeconds transition in the v1Beta2 API

kubernetes-sigs · Oct 4, 2024 · 44168ad · 44168ad
1 parent 9569cd6
commit 44168ad
Showing 1 changed file with 5 additions and 2 deletions.
diff --git a/docs/proposals/20240916-improve-status-in-CAPI-resources.md b/docs/proposals/20240916-improve-status-in-CAPI-resources.md
@@ -420,14 +420,17 @@ type MachineReadinessGate struct {
 
 | v1beta1 (tentative Dec 2024) | v1Beta2 (tentative Apr 2025) | v1beta2 after v1beta1 removal (tentative Apr 2026) |
 |------------------------------|------------------------------|----------------------------------------------------|
-| `MinReadySeconds` (new)      | `MinReadySeconds`            | `MinReadySeconds`                                  |
+|                              | `MinReadySeconds` (renamed)  | `MinReadySeconds`                                  |
 | `ReadinessGates` (new)       | `ReadinessGates`             | `ReadinessGates`                                   |
 | other fields...              | other fields...              | other fields...                                    |
 
 Notes:
-- Both `MinReadySeconds` and `ReadinessGates` should be treated as other in-place propagated fields (changing them should not trigger rollouts).
+- As of today v1beta1 MachineDeployments, MachineSets, MachinePools already have a `spec.MinReadySeconds` field. 
+  In v1beta2 those field are going to be migrated to MachineDeployments, MachineSets, MachinePools `spec.template.spec.MinReadySeconds` field, which is
+  the `MinReadySeconds` field added in the first line of the table above.
 - Similarly to Pod's `ReadinessGates`, also Machine's `ReadinessGates` accept only conditions with positive polarity;
   The Cluster API project might revisit this in the future to stay aligned with Kubernetes or if there are use cases justifying this change.
+- Both `MinReadySeconds` and `ReadinessGates` should be treated as other in-place propagated fields (changing them should not trigger rollouts).
 
 #### Machine Print columns