This message was deleted.

@orange-keyboard-57616 I think this is a somewhat contentious issue. @breezy-hamburger-69619 and @gorgeous-egg-16927 both believe we should not enrich job awaiting behavior, and I think we should.

The main to keep in mind is that k8s Jobs are intentionally not really defined beyond “ensuring the specified number of them successfully terminate.” Waiting for a particular amount of time for it to successfully terminate can be immediate, a handful of minutes, or multiple hours / days, and it’s not something we can perceive from Kubernetes. There could also be the case where other pulumi objects depend on said Job and if that Job is long-running and the user wants to wait for completion, this could cause all sorts of unrelated issues w.r.t timeouts, back-off timeout handlers etc across k8s and Pulumi, not to mention if there’s an error that isn’t discovered until some time much after the Job has begun. I’d be interested in how seeing what agreement we can reach to get this enabled

Why can’t we let users specify how they want to wait for Jobs in the annotations though?

I’m not attached to the means of how users enable this, more so, understanding the expectation users have around waiting for jobs and how we can recover from any potential errors across both pulumi & k8s

@breezy-hamburger-69619 @creamy-potato-29402 Worth including details on this on the issue as well? I am inclined to think it should be possible to make what @incalculable-diamond-5088 outlines in that issue possible - but would love to hear the details of issues that may make it hard to do reliably in an opt-in basis in notes on the issue.

Built into

kubectl

is

kubectl wait --for=condition=complete --timeout=30s [name of job]

.