-
Notifications
You must be signed in to change notification settings - Fork 1.4k
✨ KCP: Extend rollout logic for in-place updates #12840
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ KCP: Extend rollout logic for in-place updates #12840
Conversation
|
No worries, this still contains #12817. This PR is much smaller :) (but still needs some polishing) |
|
/test pull-cluster-api-e2e-main |
09f230e to
0f0f15e
Compare
0f0f15e to
6cee4f8
Compare
|
/test pull-cluster-api-e2e-main |
Signed-off-by: Stefan Büringer [email protected]
6cee4f8 to
41b6683
Compare
|
Ready for review /assign @fabriziopandini |
|
/test pull-cluster-api-e2e-main |
Signed-off-by: Stefan Büringer [email protected]
|
/test pull-cluster-api-e2e-main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks a lot, this is a solid start for introducing in-place update logic!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work, only one question from my side
| // If a Machine is marked for deletion it is not eligible for in-place update. | ||
| if _, ok := machine.Annotations[clusterv1.DeleteMachineAnnotation]; ok { | ||
| res.EligibleForInPlaceUpdate = false | ||
| } | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if we should expand use cases where a machine is not eligible for in-place:
- what if the machines has the manual remediation label? (it is another way to mark for deletion)
- what about if unhealthy in the MHC sense? (most likely it will be remediated before upgrading in place)
- what about if the machine has some control plane component unhealthy (TBD)
- what if the machine is already updating in place (as a safeguard to to trigger update in place twice)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this func should be responsible for all of this. I think it would mean pulling in code from various parts of the code base (remediation, preflight checks, condition calculation, ...) into the UpToDate func
I added a note in the umbrella issue so we can come back to this comment in 2-3 PRs? (once we have a better understanding how the overall logic for in-place looks like).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK, let's get back to this later
|
/lgtm /hold feel free to unhold |
|
LGTM label has been added. Git tree hash: 45e8b2a732bbe46ba1f5361de00134d60b846372
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold cancel |
Signed-off-by: Stefan Büringer [email protected]
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Part of #12291