Repository navigation
Conversation
sweb
force-pushed
the
feat/ttl-after-finished
branch
3 times, most recently
from
October 30, 2026 15:41
ffdad7f to
a9c859a
Compare
sweb
force-pushed
the
feat/ttl-after-finished
branch
from
October 30, 2026 15:52
a9c859a to
7b2771a
Compare
sweb
marked this pull request as ready for review
October 30, 2026 15:54
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Closes #774
Adds the field
job.config.ttlAfterFinishedto set how long the spark-submit Job is kept around. This is useful, because the operator now moves the ownership of the driver pod, the serviceaccount and config maps that were created for this SparkApplication to the Job, once the driver pod finishes (either with Succeeded or Failed).There are three possible values for
ttlAfterFinished:never: The Job never gets deleted and sticks around until the SparkApplication (its owner) gets deleted.10m(which is the default): The job sticks around for the specified duration and then gets deleted - this then also deletes the mentioned resources that have the job as owner.0s: Or any other variant that results in a duration of0s- this deletes the Job and the other resources right away.There is a special case to consider: In case of a fixed pod name via
spark.kubernetes.driver.pod.namewithretryOnFailureCount > 0thettlAfterFinishedis set to 0 and the driver pod gets deleted right away so that the retry can happen as it is going to use the same driver pod name.Definition of Done Checklist
Author
Reviewer
Acceptance
type/deprecationlabel & add to the deprecation scheduletype/experimentallabel & add to the experimental features tracker