[
https://issues.apache.org/jira/browse/SPARK-59882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dongjoon Hyun updated SPARK-59882:
----------------------------------
Parent Issue: SPARK-61265 (was: SPARK-58286)
> SuspendUtils's holdForSuspend swallows a failed Workload release without any
> warning
> -------------------------------------------------------------------------------------
>
> Key: SPARK-59882
> URL: https://issues.apache.org/jira/browse/SPARK-59882
> Project: Spark
> Issue Type: Sub-task
> Components: Kubernetes
> Affects Versions: kubernetes-operator-1.1.0
> Reporter: Qi Tan
> Priority: Minor
>
> Followup:
> [https://github.com/apache/spark-kubernetes-operator/pull/909#discussion_r4137432026]
> This rationale applies to {{holdForSuspend}} above as well, which is not
> changed by this PR, so a follow-up JIRA issue is fine.
> {{KueueWorkloadUtils.releaseWorkload}} swallows a failed {{Workload}}
> deletion, and the hold then publishes a normal {{SuspendHeld}} without the
> release addendum and requeues after 30 minutes, without any warning. For
> example, if the Role of the operator lacks {{delete}} on {{{}workloads{}}},
> or an admission webhook fails the deletion, the pending {{Workload}} of a
> suspended resource can be admitted into quota which nothing uses, while only
> the operator log says so. The dequeued path reports the same failure as
> {{KueueAdmissionRequestFailed}} (see
> {{{}failedReleaseOfPendingKueueWorkloadHoldsDequeuedCluster{}}}), and the
> reason given in the Javadoc of {{{}releaseWorkload{}}}, "the Workload is
> garbage collected with its owner anyway", doesn't hold for a suspended owner.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
