📖 in-place updates: propose configurable fallback strategy - #14035
📖 in-place updates: propose configurable fallback strategy#14035LiangquanLi930 wants to merge 1 commit into
Conversation
kubernetes-prow
Bot
added
do-not-merge/needs-area
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
kubernetes-prow
Bot
added
the
do-not-merge/work-in-progress
2e21be3 to
f70ba1c
Compare
|
/area provider/core |
kubernetes-prow
Bot
added
area/provider/core
f70ba1c to
64ec2a9
Compare
kubernetes-prow
Bot
removed
the
do-not-merge/work-in-progress
|
/area documentation |
kubernetes-prow
Bot
added
the
area/documentation
64ec2a9 to
035f877
Compare
elmiko
left a comment
elmiko
left a comment
There was a problem hiding this comment.
i think this makes sense to me, should we have an example of the condition that will be added?
Introduce an opt-in `inPlaceFallback` field (Replace/Stop) so users can require in-place-only updates. Default stays Replace; Stop halts the rollout and surfaces a condition instead of replacing Machines. Signed-off-by: Liangquan Li <liangquan.li@smartx.com>
035f877 to
3d4b49b
Compare
@elmiko Thanks for the suggestion. I've added an example of the condition here: https://github.com/kubernetes-sigs/cluster-api/compare/035f8772a8b41b6060c48d4663fac1fae88cd4b6..3d4b49bff1b8c201f32220dd6577cb8c0f3e991a |
elmiko
left a comment
elmiko
left a comment
There was a problem hiding this comment.
looks great, thanks for the update!
/lgtm
kubernetes-prow
Bot
added
the
lgtm
|
LGTM label has been added. DetailsGit tree hash: 94de56228b23df0b6eb046f904643ff4c42e2671 |
|
/assign @enxebre @fabriziopandini @sbueringer Got LGTM from @elmiko. This is a follow-up to the in-place updates proposal (#11029) — would appreciate an approve when you have a moment. |
|
/assign @enxebre @fabriziopandini @sbueringer |
|
This needs careful consideration, please don't ping us every few days (4 pings now in 4 days) |
Sorry for the frequent pings. I'll try to keep my fingers under control 😅. (I thought the assign hadn't gone through — it didn't seem to take effect — so I retried a couple of times.) |
5 participants
What this PR does:
This PR iterates on the CAPI In-Place Updates proposal (20240807-in-place-updates.md) by introducing a Configurable Fallback Strategy — a new inPlaceFallback field that lets cluster users control what happens when an in-place update cannot proceed, instead of always silently falling back to rolling replacement.
why we need it:
Today, when an in-place update cannot cover the full diff (e.g. the registered extension lacks support for a given change, or KCP preflight checks flag the candidate Machine), CAPI implicitly falls back to a rolling update that replaces Machines. For workloads where Machine replacement is expensive or destructive — bare metal nodes, nodes with local storage, license-bound nodes — this default behavior is unacceptable. Users would rather have the rollout stop and surface a condition so they can intervene, than lose irreplaceable Machines to an implicit fallback.
Change scope:
Which issue(s) this PR fixes :
NONE