Skip to content

Add support for Preservation of Machines and Backing nodes#1059

Open
thiyyakat wants to merge 79 commits intogardener:masterfrom
thiyyakat:feat/preserve-machine
Open

Add support for Preservation of Machines and Backing nodes#1059
thiyyakat wants to merge 79 commits intogardener:masterfrom
thiyyakat:feat/preserve-machine

Conversation

@thiyyakat
Copy link
Member

@thiyyakat thiyyakat commented Dec 10, 2025

What this PR does / why we need it:

This PR introduces a feature that allows operators and endusers to preserve a machine/node and the backing VM for diagnostic purposes.

The expected behaviour, use cases and usage are detailed in the proposal that can be found here

Which issue(s) this PR fixes:
Fixes #1008

Special notes for your reviewer:

The following tests were carried out serially with the machine-controller-manager-provider-virtual: #1059 (comment)

Please also take a look at the questions asked here.

Release note:

Introduce support for preservation of machines (both Running and Failed), and the backing node (if it exists). 

@gardener-robot gardener-robot added kind/api-change API change with impact on API users needs/second-opinion Needs second review by someone else needs/rebase Needs git rebase labels Dec 10, 2025
@gardener-robot
Copy link

@thiyyakat You need rebase this pull request with latest master branch. Please check.

@gardener-robot gardener-robot added needs/review Needs review size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Dec 10, 2025
@thiyyakat thiyyakat force-pushed the feat/preserve-machine branch 2 times, most recently from 06ecf58 to 89f2900 Compare December 10, 2025 12:06
@thiyyakat
Copy link
Member Author

thiyyakat commented Dec 11, 2025

Questions that remain unanswered:

  1. On recovery of a preserved machine, it transitions from Failed to Running. However, if the preserve annotation was when-failed, then the node continues to be preserved in Running even though the annotation says when-failed - is that okay? The node needs to be preserved so that pods can get scheduled onto it without CA scaling it down.
    Update: We allow the annotation to stay, but we clear PreserveExpirTime and set the node condition to false. The CA annotation remains until manually removed from node.
  2. drain timeout is checked currently by calculating time from LastUpdateTime (from when machine moved to Failed) to now. Is there a better way to do it?
    timeOutOccurred = utiltime.HasTimeOutOccurred(machine.Status.CurrentStatus.LastUpdateTime, timeOutDuration)
    In the normal drain, it is checked wrt DeletionTimestamp
  3. In some parts of the code, checks are performed to see if the returned error is due to a Conflict, and ConflictRetry rather than ShortRetry is returned. When should these checks be performed? The preservation flow has a lot of update calls. : Addressed. Use ConflictRetry when appropriate.

Copy link
Member Author

@thiyyakat thiyyakat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: A review meeting was held today for this PR. The comments were given during the meeting.

During the meeting, we revisited the decision to move drain to Failed state for preserved machine. The reason discussed previously was that it didn't make sense semantically to move the machine to Terminating and then do the drain, because there is a possibility that the machine may recover. Since Terminating is a final state, the drain (separate from the drain in triggerDeletionFlow) will be performed in Failed phase. There was no change proposed during the meeting. This design decision was only reconfirmed.

Copy link
Member

@takoverflow takoverflow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have only gone through half of the PR, have some suggestions PTAL.

@gardener-robot gardener-robot added the needs/changes Needs (more) changes label Dec 18, 2025
@thiyyakat thiyyakat force-pushed the feat/preserve-machine branch from 22c646e to 7c062b5 Compare December 19, 2025 08:30
@thiyyakat thiyyakat force-pushed the feat/preserve-machine branch from e2a7ea7 to 74603a4 Compare December 31, 2025 09:56
@thiyyakat thiyyakat marked this pull request as ready for review January 6, 2026 05:56
@thiyyakat thiyyakat requested a review from a team as a code owner January 6, 2026 05:56
@thiyyakat thiyyakat force-pushed the feat/preserve-machine branch 2 times, most recently from a487a18 to 508b1ba Compare January 12, 2026 04:24
Copy link
Member

@aaronfern aaronfern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR @thiyyakat!
A few questions/nits from me, please address them

UpdateFailed string = "UpdateFailed"
)

const (
Copy link
Member

@elankath elankath Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These condition constants feel like they are in the wrong place as we already have conditions at pkg/apis/machine/types.go. Also, I don't think the Node prefix should be used for the condition constant names as they are used in Machine objects too. @unmarshall should these even be exposed in API ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added them here after seeing the constants for InPlaceUpdates added just above:

NodeInPlaceUpdate corev1.NodeConditionType = "InPlaceUpdate"

The NodeCondition for InPlace is named NodeInPlaceUpdate, and I've followed the same.

@elankath , @unmarshall , please let me know what change you would like me to make.

Copy link
Member

@elankath elankath Jan 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thiyyakat Ok, but the the reason constants like NodePreservedByMCM, etc should just be PreservedByMCM - that is also the convention followed by in-place update constants.

PreservedNodeDrainSuccessful -> DrainSuccessful

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will make the change to the other constant names and shorten them.

This one: PreservedNodeDrainSuccessful -> DrainSuccessful I am unsure of what to do. DrainSuccessful is used as a Reason for InPlaceUpdate, and the comment indicates the same. Is it okay to re-use it for a Message?
Ref:

// DrainSuccessful is a constant for reason in condition that indicates node drain is successful

thiyyakat added 24 commits March 9, 2026 16:30
- Modify sort function to de-prioritize preserve machines
- Add test for the same
- Improve logging
- Fix bug in stopMachinePreservationIfPreserved when node is not found
- Update default MachinePreserveTimeout to 3 days as per doc
- Reuse function to write annotation on machine
- Minor refactoring
- Make changes to add auto-preserve-stopped on recovered, auto-preserved previously failed machines.
- Change stopMachinePreservationIfPreserved to removeCA annotation when preserve=false on a recovered failed, preserved machine
* remove stop annotation value
* remove CA scale-down annotation when preservation stops
* change preservation annotation handling semantics for machine and node
* remove auto-preserve-stopped annotation value
* Add preserveExpiryTime to NodeCondition.Message
* modify test cases
…eserved machines if autoPreservedFailedMachineMax is decreased in the shoot spec.
…liedNodePreserveValue for persisting node annotation values that have been applied.
Copy link
Member

@takoverflow takoverflow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have requested a couple of minor changes, PTAL

for _, m := range machinesWithoutUpdateSuccessfulLabel {
if machineutils.IsMachineFailed(m) {
staleMachines = append(staleMachines, m)
if c.shouldFailedMachineBeTerminated(m) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this function be renamed to isFailedMachineBeingPreserved? To clarify the intent better (This would require reversing the semantics of the bool returned though, and the check here needs to be inverted). WDYT

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was a bit of a discussion on this: #1059 (comment).

Please let me know if you still feel the change is required.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still see value in explicitly conveying what the function is checking. Rather than making it ambiguous and then needing to look at the function definition to realise that the criteria being used for terminating failed machine is just preservation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aaronfern and @r4mek . WDYT?

takoverflow - part 1
@thiyyakat thiyyakat force-pushed the feat/preserve-machine branch from 4e8c12f to 1538501 Compare March 11, 2026 08:31
Copy link
Member

@gagan16k gagan16k left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few minor changes

gagan16k - part 2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. cla: yes Indicates the PR's author has signed the cla-assistant.io CLA. kind/api-change API change with impact on API users needs/changes Needs (more) changes needs/rebase Needs git rebase needs/review Needs review needs/second-opinion Needs second review by someone else size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support Preservation of Failed Machines for diagnostics

7 participants