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
UPSTREAM: <carry>: fix(test): drop blocking namespace-deletion wait between both-watch-modes scenarios
The both-watch-modes test loops over two scenarios (singlens, ownns) inside
a single It block and was blocking on full namespace deletion between them.
This caused flaky 300s timeouts on GCP techpreview clusters where master
nodes run at 94-99% CPU, which starves the namespace controller and makes
namespace termination arbitrarily slow.
The wait was not guarding anything real:
- EnsureCleanupClusterExtension already ensures the CE and CRD are gone;
since CE deletion uses ForegroundPropagation, the ClusterObjectSet teardown
must complete before the CE disappears, meaning all managed resources
(Deployments, Services, etc.) are already deleted at that point.
- The singleown bundle installs no ValidatingWebhookConfiguration or
MutatingWebhookConfiguration, so there is no webhook admission risk.
- Each scenario generates unique namespace names and CRD group suffixes via
rand.String(4), so a terminating namespace from scenario 1 cannot collide
with or interfere with scenario 2's resources.
Trigger both namespace deletions and proceed without waiting. The DeferCleanup
registrations that already exist will handle any residual cleanup after the
spec exits.
Fixes: OCPBUGS-84943
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Todd Short <tshort@redhat.com>
0 commit comments