-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
🌱 Preserve finalizers during MS/Machine reconciliation #10694
🌱 Preserve finalizers during MS/Machine reconciliation #10694
Conversation
/hold (cc @vincepri @fabriziopandini @enxebre @chrischdi please note "My current take" in the PR description) |
7c008ab
to
cfddc5b
Compare
internal/controllers/machinedeployment/machinedeployment_sync.go
Outdated
Show resolved
Hide resolved
cfddc5b
to
38c0b38
Compare
@vincepri PTAL :) (updated PR description) |
38c0b38
to
1f83a1f
Compare
@@ -123,6 +124,17 @@ func MachineDeploymentScaleSpec(ctx context.Context, inputGetter func() MachineD | |||
Replicas: 1, | |||
WaitForMachineDeployments: input.E2EConfig.GetIntervals(specName, "wait-worker-nodes"), | |||
}) | |||
|
|||
By("Deleting the MachineDeployment with foreground deletion") |
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.
Just added this test to verify that foreground deletion works at the moment.
Long-term we would like to have the same behavior as with the Cluster (that MD is deleted "in the foreground" independent of if foreground or background deletion is used)
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.
Do we have an issue to discuss "Implement forced foreground deletion"?
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.
I would create one.
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.
xref: #10710
@@ -257,15 +257,8 @@ func (r *Reconciler) computeDesiredMachineSet(ctx context.Context, deployment *c | |||
name = existingMS.Name |
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.
// Add foregroundDeletion finalizer to MachineSet if the MachineDeployment has it.
if sets.New[string](deployment.Finalizers...).Has(metav1.FinalizerDeleteDependents) {
finalizers = []string{metav1.FinalizerDeleteDependents}
}
in l.234
I think this code is basically unreachable. Because we never create a MachineSet after the deletionTimestamp is already set. And the finalizer and the deletionTimestamp seem to be set by the kube-apiserver through the delete call at the same time:
- The Kubernetes API server sets the object's metadata.deletionTimestamp field to the time the object was marked for deletion.
- The Kubernetes API server also sets the metadata.finalizers field to foregroundDeletion.
- The object remains visible through the Kubernetes API until the deletion process is complete.
https://kubernetes.io/docs/concepts/architecture/garbage-collection/#foreground-deletion
Technically someone could send the foregroundDeletion finalizer already earlier, but I think in any case the finalizer would be propagated down (see e2e test coverage)
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.
Done
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.
wouldn't this bit of code ensure that when you are removing a MD with foreground (via client), then foreground would be also honoured between the owned MS deletion and their child Machines?
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.
I think it doesn't change that behavior. I did the following test with this PR:
- Create Cluster & MD
- Add additional "test" finalizer to MS & Machine
- Delete MD with foreground
- Check that:
- MD gets the foregroundDeletion finalizer + deletionTimestamp
- MS gets the foregroundDeletion finalizer + deletionTimestamp
- Machine gets the deletionTimestamp
Then I:
- Removed test finalizer from Machine => Machine went away
- Removed test finalizer from MachinSet => MachineSet and then MachineDeployment went away
Please note that computeDesiredMachineSet is not executed anymore after the deletionTimestamp has been set on MachineDeployment (because we run reconcileDelete instead)
So I think this is:
- unreachable code (except in the case where someone already sets the foregroundDeletion finalizer on the MD manually before MD deletion)
- and anyway already additionally done by the kube-controller-manager
/lgtm |
LGTM label has been added. Git tree hash: 59d8b33236837b721d8bf625c4326200c6b63c34
|
1f83a1f
to
4d0e5f9
Compare
/test pull-cluster-api-e2e-main |
/lgtm |
LGTM label has been added. Git tree hash: d9c59de32cd9277b532cca2838f4d94fa6bc45d9
|
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! Preserving finalizers makes more sense than the current behaviour
q: should we retitle the PR to surface this as a main point of this PR?
Expect(input.ClusterProxy.GetClient().Delete(ctx, input.MachineDeployment, &client.DeleteOptions{PropagationPolicy: input.DeletePropagationPolicy})).To(Succeed()) | ||
|
||
log.Logf("Waiting for MD to be deleted") | ||
Eventually(func(g Gomega) { |
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.
q: should we also check that all the machines are gone? (so we check one layer more of the hierarchy)
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.
Done
Signed-off-by: Stefan Büringer [email protected]
4d0e5f9
to
049a781
Compare
/test pull-cluster-api-e2e-main |
Done |
/lgtm |
LGTM label has been added. Git tree hash: 4cdcfed36001da741a45ae48c046fdd94c119e42
|
@fabriziopandini @chrischdi @vincepri ready to merge? |
@fabriziopandini @chrischdi @vincepri can we merge this PR? |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri 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:
We had some discussion around what the proper behavior is.
My current take is:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #