Skip to content

fix(spur-k8s): keep the cancel of a deleted SpurJob - #808

Open
pre wants to merge 1 commit into
ROCm:mainfrom
silogen:pr/spurjob-cancel
Open

fix(spur-k8s): keep the cancel of a deleted SpurJob#808
pre wants to merge 1 commit into
ROCm:mainfrom
silogen:pr/spurjob-cancel

Conversation

@pre

@pre pre commented Sep 2, 2026

Copy link
Copy Markdown

Related:

Motivation

Deleting a SpurJob while its job is still queued leaves the job in the
controller's queue for good. The Kubernetes object disappears, so nothing points at
the job any more, but it keeps its place in the queue and keeps holding whatever it
was waiting for. The only way out is to cancel it by hand through the CLI, and the
operator gives no sign that anything went wrong.

Technical Details

handle_deletion called cancel_job and discarded the result, then removed the
finalizer regardless. Any failure, a transient connection error included, was
silent and unrecoverable, because once the finalizer is gone the operator never
sees the object again.

It now inspects the result. NotFound is success, since the goal is that the
controller no longer holds the job. Any other failure returns
ReconcileError::Other, so the finalizer stays and the delete is retried on the
next reconcile until the cancel is confirmed.

Related:

Test Plan

  1. Submit a job that cannot be scheduled, so it stays Pending.
  2. Delete the SpurJob object.
  3. Check the controller queue.

Test Result

Environment: three node RKE2 cluster on cloud VMs, 8 vCPU and 96 GiB each, no GPU.

  • A Pending job that asked for 64 CPUs, more than any node has, was deleted as a
    SpurJob. spur queue no longer holds it, and the object is gone.
  • Before the change the same sequence left the job in the queue with no object.
  • cargo clippy --workspace --exclude spur-ffi --all-targets --locked reports
    nothing; cargo test --locked passes 3522 tests.

Submission Checklist

handle_deletion discarded the result of cancel_job. A job that had no Pod
yet, one waiting for resources, lives only in the controller queue, so a
lost cancel left it there for ever: the custom resource went away, the
finalizer was removed, and nothing was left that could cancel the job.
Observed with a job that asked for more CPUs than any node has.

The result is now checked. A failure is logged and returned, so the
finalizer retries before the SpurJob is removed. NotFound is treated as
success, because it means the controller has already forgotten the job.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant