You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The node-agent DaemonSet deletion path doesn't check errors.IsNotFound(err) before treating a delete failure as a real error — unlike the adjacent ConfigMap deletion path in the same reconciler, which does handle this correctly.
Recommended fix: add errors.IsNotFound(err) handling after the r.Delete() call — when the delete fails with NotFound, treat it as success (the DaemonSet is already gone), matching the ConfigMap path's existing behavior.
Affected versions (confirmed present in all)
Branch
File
Line
oadp-dev
internal/controller/nodeagent.go
278
oadp-1.6
internal/controller/nodeagent.go
278
oadp-1.5
internal/controller/nodeagent.go
214
oadp-1.4
controllers/nodeagent.go
152
How this was found
Surfaced by this repo's own automated e2e log-analysis tooling on ci/prow/4.23-e2e-test-aws for PR #2206 (oadp-1.6, unrelated change — veleroPredicate/annotation-change reconciliation): the AfterEach cleanup of "Configuration testing for DPA Custom Resource" (tests/e2e/dpa_deployment_suite_test.go) hit a DeleteDaemonSetFailed event while the velero pod was stuck PodInitializing, failing the test. The analysis explicitly concluded: "Likely Cause: Real bug in the OADP operator's DaemonSet reconciliation logic. Not a flake, not environmental." None of the known-flake patterns in tests/e2e/lib/flakes.go matched.
This appears to be a pre-existing, long-standing bug rather than something introduced by #2206 — it just happened to get exercised by that PR's e2e run.
Bug
The node-agent DaemonSet deletion path doesn't check
errors.IsNotFound(err)before treating a delete failure as a real error — unlike the adjacent ConfigMap deletion path in the same reconciler, which does handle this correctly.Recommended fix: add
errors.IsNotFound(err)handling after ther.Delete()call — when the delete fails with NotFound, treat it as success (the DaemonSet is already gone), matching the ConfigMap path's existing behavior.Affected versions (confirmed present in all)
oadp-devinternal/controller/nodeagent.gooadp-1.6internal/controller/nodeagent.gooadp-1.5internal/controller/nodeagent.gooadp-1.4controllers/nodeagent.goHow this was found
Surfaced by this repo's own automated e2e log-analysis tooling on
ci/prow/4.23-e2e-test-awsfor PR #2206 (oadp-1.6, unrelated change —veleroPredicate/annotation-change reconciliation): theAfterEachcleanup of "Configuration testing for DPA Custom Resource" (tests/e2e/dpa_deployment_suite_test.go) hit aDeleteDaemonSetFailedevent while the velero pod was stuckPodInitializing, failing the test. The analysis explicitly concluded: "Likely Cause: Real bug in the OADP operator's DaemonSet reconciliation logic. Not a flake, not environmental." None of the known-flake patterns intests/e2e/lib/flakes.gomatched.Log: https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_oadp-operator/2206/pull-ci-openshift-oadp-operator-oadp-1.6-4.23-e2e-test-aws/2087353890981810176
This appears to be a pre-existing, long-standing bug rather than something introduced by #2206 — it just happened to get exercised by that PR's e2e run.
Note
Responses generated with Claude