dongjoon-hyun opened a new pull request, #904: URL: https://github.com/apache/spark-kubernetes-operator/pull/904
### What changes were proposed in this pull request? This PR aims to record the Kueue `PodsReady` condition on the `Workload` of a started `SparkApplication` or `SparkCluster`, like the Kueue built-in integrations. - The condition becomes `True` with the reason `Started` once the ready pods of each pod set reach its `count`. These are the driver and `spark.executor.instances` executors of a `SparkApplication`, or the master and workers of a `SparkCluster`. The pods are counted once per reconciliation from the existing pod informer cache, and `AppRunningStep` shares that count for its executor thresholds. - `AppRunningStep` records it from `DriverReady` on. `ClusterSuspendStep` records it for a `RunningHealthy` cluster which is not suspended, since `RunningHealthy` does not wait for the pods. That includes a `Workload` kept after a `PodsReadyTimeout`, since Kueue keeps counting its quota, and with `blockAdmission` it would otherwise block every other workload. - Unlike the built-in integrations, the condition is not set back to `False` when a pod is lost later, e.g. an executor which Spark replaces, so the `recoveryTimeout` of Kueue does not apply. - The status update goes through the fail-closed admission webhook of Kueue, so the client does not retry it in place. A conflict or a transport-level failure is retried after 5 seconds. A persistent failure publishes the new `KueuePodsReadyUpdateFailed` warning event and is retried with the default interval. - The `Workload` of a `SparkApplication` whose executors are not pods, e.g. with the `spark://` master URL of a `SparkCluster`, has the driver pod set only. - The `Workload` informers map a `Workload` to its owner by its owner reference instead of the `spark.operator/spark-app-name` or `spark.operator/spark-cluster-name` label. A `Workload` copies the labels of its owner, so such a label may name another resource, e.g. for a `SparkCluster` labeled after an application. - The Kueue E2E test runs with a shortened `waitForPodsReady` timeout (2 minutes). A new step checks that a `SparkCluster` whose pods are ready is not evicted, while one whose worker is never scheduled is evicted by `PodsReadyTimeout`. ### Why are the changes needed? Kueue enables [waitForPodsReady](https://kueue.sigs.k8s.io/docs/tasks/manage/setup_wait_for_pods_ready/) by default since v0.19, with a 30-minute timeout. Since the operator does not report `PodsReady`, Kueue evicts every Spark resource which stays admitted longer than the timeout by `PodsReadyTimeout`, e.g. every long-running `SparkCluster`. With `blockAdmission`, an admitted Spark resource also blocks the admission of every other workload. ### Does this PR introduce _any_ user-facing change? No for the released versions, because the Kueue integration is not released yet in [1.0.0](https://github.com/apache/spark-kubernetes-operator/releases/tag/1.0.0) (2026-07-23). ### How was this patch tested? Pass the CIs with the newly added test cases. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Opus 5.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]
