Skip to content

Commit 1ac058c

Browse files
author
Yuvaraj Kakaraparthi
committed
update lifecycle hooks documentation with new upgrade rules
1 parent 5ada8cb commit 1ac058c

File tree

1 file changed

+12
-0
lines changed

1 file changed

+12
-0
lines changed

docs/book/src/tasks/experimental-features/runtime-sdk/implement-lifecycle-hooks.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -115,6 +115,12 @@ This hook is called after the Cluster object has been updated with a new `spec.t
115115
immediately before the new version is going to be propagated to the control plane (*). Runtime Extension implementers
116116
can use this hook to execute pre-upgrade add-on tasks and block upgrades of the ControlPlane and Workers.
117117

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+
118124
#### Example Request:
119125

120126
```yaml
@@ -158,6 +164,12 @@ and immediately before the new version is going to be propagated to the MachineD
158164
Runtime Extension implementers can use this hook to execute post-upgrade add-on tasks and block upgrades to workers
159165
until everything is ready.
160166

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.
172+
161173
#### Example Request:
162174

163175
```yaml

0 commit comments

Comments
 (0)