Refactor ConfigMap-based teardown and remove DaemonSet finaliser #438
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
frobware
force-pushed
the
fix-finalizers
branch
2 times, most recently
from
ca3856b to
d7128f9
Compare
|
@frobware, this pull request is now in conflict and requires a rebase. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #438 +/- ##
===========================
===========================
☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Previously, a finaliser was added to the DaemonSet, which blocked its
deletion unless explicitly removed. However, the operator only watched
the ConfigMap—not the DaemonSet—so forced DaemonSet deletions went
unnoticed, and the DaemonSet was never recreated.
This change reworks that behaviour to match standard Kubernetes
operator design:
- Adds a `Watches(&DaemonSet{}, EnqueueRequestsFromMapFunc(...))` that
maps all DaemonSet events back to the ConfigMap. This enables
self-healing: if the DaemonSet is deleted, the operator observes the
event and recreates it.
- Removes the DaemonSet finaliser entirely. It's unnecessary because
the parent ConfigMap holds the only finaliser. This is in line with
Kubernetes guidance: only finalise the resource responsible for
managing others.
- Replaces monolithic teardown with ordered, step-wise deletion of
managed resources (DaemonSet, CSIDriver, SCC), requeuing between
each step. This ensures deletion is safe, idempotent, and resilient
to propagation delays or transient failures.
- Removes the ConfigMap finaliser only after all dependent resources
have been confirmed deleted. This prevents race conditions and
ensures a clean operator shutdown.
These changes bring the controller in line with normal operator
architecture: use a single "source of truth" object (ConfigMap in this
case), watch and reconcile dependents explicitly, and rely on
finalisers only where needed.
Signed-off-by: Andrew McDermott <[email protected]>
frobware
pushed a commit
to frobware/bpfman-operator
that referenced
this pull request
May 6, 2025
…s/component-update-ocp-bpfman-operator-bundle chore(deps): update ocp-bpfman-operator-bundle to 227930a
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TODO:
Note: If either the SCC or the CSIDriver is manually removed, it will not be recreated.
Previously, a finaliser was added to the DaemonSet, which blocked its deletion unless explicitly removed. However, the operator only watched the ConfigMap—not the DaemonSet—so forced DaemonSet deletions went unnoticed, and the DaemonSet was never recreated.
This change reworks that behaviour to match standard Kubernetes operator design:
Adds a
Watches(&DaemonSet{}, EnqueueRequestsFromMapFunc(...))that maps all DaemonSet events back to the ConfigMap. This enables self-healing: if the DaemonSet is deleted, the operator observes the event and recreates it.Removes the DaemonSet finaliser entirely. It's unnecessary because the parent ConfigMap holds the only finaliser. This is in line with Kubernetes guidance: only finalise the resource responsible for managing others.
Replaces monolithic teardown with ordered, step-wise deletion of managed resources (DaemonSet, CSIDriver, SCC), requeuing between each step. This ensures deletion is safe, idempotent, and resilient to propagation delays or transient failures.
Removes the ConfigMap finaliser only after all dependent resources have been confirmed deleted. This prevents race conditions and ensures a clean operator shutdown.
These changes bring the controller in line with normal operator architecture: use a single "source of truth" object (ConfigMap in this case), watch and reconcile dependents explicitly, and rely on finalisers only where needed.