This message was deleted.

We’ve discussed the Job resource a bit before, but haven’t settled on semantics that would be useful for Pulumi users. The main problem is that Jobs can encompass all sorts of behavior, and we don’t have any way of knowing what is expected behavior. Currently, we don’t have any await logic for Jobs; Pulumi creates the resource and doesn’t take further action. That being said, we’re very interested to hear your use cases and figuring out how we can support those workflows in Pulumi. See also: https://github.com/pulumi/pulumi-kubernetes/issues/449

This is currently just a rails api db migration. As-is, these will mostly run quickly. We have multiple replicas so we don’t want to just add this to the start script like the pulumi rails example. Running as a job we can guarantee parallelism/completion

Yeah, DB migrations are the most common use case we’ve seen for Jobs. Pulumi will properly wait on readiness checks in the Pods, so that might be good enough for now.

I’m guessing I’ll still have to add random job names and deal with cleanup separately as well still.

Your use-case is a common one. The reality is that a k8s Job can mean a lot of different things to different people so capturing, let alone generalizing a Job’s “completeness” is subjective. Specifically, Jobs only run once until completeness and never again. For you to force a Job to always be created you must work around it by forcing spec changes e.g. inserting a random string or changing commit hash into labels etc. And as you’ve pointed out, Job Pods don’t get cleaned up by design [1]. The ttl feature you pointed out is new and around as of 1.12 in a alpha state. 1 - https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#job-termination-and-cleanup