[rambohe-ch]

Reason for Change:

Cluster Status Reporter emits clusterBBRNotReady when BBR is scaled to zero fails intermittently on a cluster where the status reporter runs with the chart defaults:

timed out waiting for reporter event reason=clusterBBRNotReady object="" newer than 0001-01-01 00:00:00 +0000 UTC

A Deployment scaled to zero has no pods, so the reporter debounces it by first observation. It sees the problem on the next resync, and only publishes once a later resync finds it has lasted the startup grace. The specs waited a fixed 3 minutes, tuned for the E2E install's 30s grace:

	--resync-seconds	--startup-grace-seconds	--event-refresh-seconds
E2E install (install-components.sh)	60	30	120
Chart defaults (values.yaml)	60	60	300

With grace equal to resync, tick jitter can push the emit one resync later. The scaled-down pod also has to terminate first (terminationGracePeriodSeconds: 30), so the worst case reaches the 180s limit.

 Cluster Status Reporter / EPP scale-to-zero
-  emitTimeout = 3 * time.Minute                  // fixed
+  timings := utils.GetReporterTimings(ctx)       // flags from the running reporter, chart defaults otherwise
+  emitTimeout = timings.DebouncedEmitTimeout()
+    = resync + ceil(grace/resync)*resync + resync (jitter) + 90s slack
+    = 270s for both settings
   recovery quiet window: 3m (unchanged)

ReporterEventRefreshInterval now reads through GetReporterTimings, with the same behaviour.

Requirements

• added unit tests and e2e tests (if applicable).

Issue Fixed:

Notes for Reviewers:

Evidence

• Before: on a cluster running the reporter with the chart defaults (--resync-seconds=60 --startup-grace-seconds=60), scaling body-based-router to zero produced clusterBBRNotReady after 78s, 189s, 189s. Two of three runs exceed the old 180s wait.
• After:
  • go test -mod=mod -count=1 ./test/e2e/utils/ → passed. It includes the new TestReporterTimingsFromArgs (defaults, E2E flags, zero grace, invalid values) and TestDebouncedEmitTimeout (the chart-defaults regression case is 270s).
  • go vet -mod=mod ./test/e2e/... → passed.
  • bin/golangci-lint run ./test/e2e/... → passed, 0 issues.
  • E2E on the same cluster, cluster_status_spec.go and control_plane_error_spec.go (!StandardK8sOnly && !Nightly && !Perf) → passed, SUCCESS! -- 7 Passed | 0 Failed.

Merge Danger

Door: two-way. Test-only: no product code changes.

Blast Radius: e2e-timing. On a real failure, the scale-to-zero specs now wait up to 270s instead of 180s. Passing runs are unchanged, because the wait returns as soon as the Event appears.