-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Remove ContainsFinalizer check before adding it ✨🐛 #4789
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
base: master
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: matrus2 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
} | ||
|
||
if added := controllerutil.AddFinalizer(busybox, busyboxFinalizer); added { | ||
log.Info("Finalizer added for Busybox") |
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.
Thank you very much for the suggestion and for taking the time to improve the code! 🙏
The reason for keeping the original implementation as it is, is because:
Separation of concerns:
We first check if the finalizer is already present using ContainsFinalizer
, and only attempt to add it if necessary. This makes the logic clear and avoids unnecessary operations.
Efficient error handling:
By explicitly checking first, we can log and manage errors more precisely at each step, which makes debugging and monitoring easier.
Avoid unnecessary API server writes:
Updating the resource only when a change is needed helps reduce API server load, avoids unnecessary reconciliation retries, and keeps the controller efficient.
Even though AddFinalizer
internally checks, doing the explicit check first improves clarity, and bring the above benefits which seems more aligned.
For these reasons, I think it might be better to keep the original implementation as it is.
Thanks again for your contribution and for sparking this valuable discussion! 🌟
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.
/hold
If you do not mind, I think we should close this one as not accepted.
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.
Thank you for the quick and thorough review
I agree that using ContainsFinalizer and AddFinalizer together improves readability. However, I still believe the original code block is misleading and can be improved. It appears to contain dead code within the conditional block:
if ok := controllerutil.AddFinalizer({{ lower .Resource.Kind }}, {{ lower .Resource.Kind }}Finalizer); !ok {
err = fmt.Errorf("finalizer for {{ .Resource.Kind }} was not added")
log.Error(err, "Failed to add finalizer for {{ .Resource.Kind }}")
return ctrl.Result{}, err
}
Since the presence of the finalizer is checked before this block (by ContainsFinalizer), the condition where AddFinalizer returns false (and thus the error logging) will never be reached. Examining the implementation of AddFinalizer confirms this, as it only appends the finalizer and returns true if it wasn't already present.
My proposal aims for a more precise approach:
if !controllerutil.ContainsFinalizer(memcached, memcachedFinalizer) {
log.Info("Adding Finalizer for Memcached")
controllerutil.AddFinalizer(memcached, memcachedFinalizer)
if err = r.Update(ctx, memcached); err != nil {
log.Error(err, "Failed to update custom resource to add finalizer")
return ctrl.Result{}, err
}
}
This revised code explicitly checks for the finalizer's absence, logs the intention to add it, performs the addition, and then handles potential errors during the update operation.
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.
@camilamacedo86 Would you agree with this approach?
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.
Hi @matrus2
Thank you for looking into that.
Your observation seems to be accurate, and your proposal seems to solve it well. 👍
Could you please update this PR with the proposal?
Also, please ensure that you squash the commits for we have a good git history.
Thank you a lot 🥇
fix: #4564
This pull request refactors the logic for adding finalizers in multiple reconciler implementations to simplify the code and improve readability. The changes replace the use of
controllerutil.ContainsFinalizer
checks with a more concise pattern that directly checks the result ofcontrollerutil.AddFinalizer
.