dongjoon-hyun opened a new pull request, #861: URL: https://github.com/apache/spark-kubernetes-operator/pull/861
### What changes were proposed in this pull request? Add `spark.kubernetes.operator.events.minIntervalSeconds` (default `300`, dynamically overridable) and enforce it in `ConfigurableEventRecorder`, the single gate every Kubernetes Event passes through. An event is dropped only when the same `(metadata.uid, reason, message)` was already published within the interval. The `message` is part of the identity because `DefaultEventSink` rewrites the `message` and the `lastTimestamp` of the existing `Event` on every repeat, so only a repeat that says exactly what the last one said carries nothing new. The first event of an identity is always published, so a rare event such as `Failed` is never delayed. The window is fixed rather than sliding, so an event repeated more often than the interval is still republished. The tracking map is bounded by an inline sweep that drops entries older than the interval, and is discarded when the feature is off. No new dependency and no background thread. An event is only published when a reconciliation emits one, so the effective period is the interval rounded up to the next repeat. The documented rule is therefore to keep this option below the interval at which the repeats are emitted (`spark.kubernetes.operator.reconciler.suspendHoldRequeueIntervalSeconds` for `SuspendHeld`, `spark.kubernetes.operator.reconciler.intervalSeconds` for `KueueAdmissionPending`), which is stricter than keeping it below the `--event-ttl` of the API server. At the default, this means `KueueAdmissionPending` bumps its `count` every 360 seconds instead of every 120, and no other event is affected: `SuspendHeld` already repeats every 1800 seconds, and the rest change their `message` between repeats. `tests/e2e/helm/events-config-values.yaml` sets the option to `0`, since the `suspend-events` suite asserts that the `count` of an unchanged `SuspendHeld` event rises within 120 seconds. A global QPS cap is deliberately not added: it would need a drop policy that sacrifices first occurrences, which is exactly what this change guarantees never happens. Event publish/drop counters are left to a separate ticket. ### Why are the changes needed? `DefaultEventSink` writes each event synchronously on the reconcile thread with a `GET` plus a `CREATE` or a `PATCH` — two API calls per event — and JOSDK has no equivalent of the client-go `EventRecorder` spam filter. A repeat whose `message` is unchanged only increments the `count`, so it pays that cost while telling the user nothing new. This is a prerequisite for defaulting `spark.kubernetes.operator.events.enabled` to `true`. That default change is out of scope here. ### Does this PR introduce _any_ user-facing change? No. Kubernetes Events were added after the [1.0.0](https://github.com/apache/spark-kubernetes-operator/releases/tag/1.0.0) release (2026-07-23) by SPARK-59502, so the whole feature this option belongs to is unreleased. It is also off by default (`spark.kubernetes.operator.events.enabled` is `false`). The new option is documented in a new "Event frequency" section of `docs/configuration.md` and in `docs/config_properties.md`. Setting it to zero or a negative value publishes every event. ### How was this patch tested? Pass the CIs with new unit tests. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Opus 5 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
