You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/book/src/tasks/experimental-features/runtime-sdk/implement-lifecycle-hooks.md
+12Lines changed: 12 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -115,6 +115,12 @@ This hook is called after the Cluster object has been updated with a new `spec.t
115
115
immediately before the new version is going to be propagated to the control plane (*). Runtime Extension implementers
116
116
can use this hook to execute pre-upgrade add-on tasks and block upgrades of the ControlPlane and Workers.
117
117
118
+
Note: While the upgrade is blocked changes made to the Cluster Topology will be delayed propagating to the underlying
119
+
objects while the object is waiting for upgrade. Example: modifying ControlPlane/MachineDeployments (think scale up),
120
+
or creating new MachineDeployments will be delayed until the target ControlPlane/MachineDeployment is ready to pick up the upgrade.
121
+
This ensures that the ControlPlane and MachineDeployments do not perform a rollout prematurely while waiting to be rolled out again for the version upgrade (no double rollouts).
122
+
This also ensures that any version specific changes are only pushed to the underlying objects also at the correct version.
123
+
118
124
#### Example Request:
119
125
120
126
```yaml
@@ -158,6 +164,12 @@ and immediately before the new version is going to be propagated to the MachineD
158
164
Runtime Extension implementers can use this hook to execute post-upgrade add-on tasks and block upgrades to workers
159
165
until everything is ready.
160
166
167
+
Note: While the MachineDeployments upgrade is blocked changes made to existing MachineDeployments and creating new MachineDeployments
168
+
will be delayed while the object is waiting for upgrade. Example: modifying MachineDeployments (think scale up),
169
+
or creating new MachineDeployments will be delayed until the target MachineDeployment is ready to pick up the upgrade.
170
+
This ensures that the MachineDeployments do not perform a rollout prematurely while waiting to be rolled out again for the version upgrade (no double rollouts).
171
+
This also ensures that any version specific changes are only pushed to the underlying objects also at the correct version.
0 commit comments