https://pulumi.com logo
#contribute
Title
# contribute
o

orange-keyboard-57616

04/16/2019, 6:02 PM
How can I help with this feature? https://github.com/pulumi/pulumi-kubernetes/issues/449. I'm willing to take a stab at it, but I have a few questions about how to attack it. Also, I want to be sure that it would be a welcomed contribution before starting on it.
c

creamy-potato-29402

04/16/2019, 8:00 PM
@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.
If we can build agreement about what to do I’m happy to help shepherd the change through
b

breezy-hamburger-69619

04/16/2019, 8:08 PM
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
c

creamy-potato-29402

04/16/2019, 8:25 PM
Why can’t we let users specify how they want to wait for Jobs in the annotations though?
b

breezy-hamburger-69619

04/16/2019, 8:50 PM
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
w

white-balloon-205

04/17/2019, 12:02 AM
@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.
o

orange-keyboard-57616

04/21/2019, 4:04 PM
Built into
kubectl
is
kubectl wait --for=condition=complete --timeout=30s [name of job]
.
If pulumi could behave similarly and error our in the case of either a timeout or a failed job, that would be ideal. I think
waitForCompletion
is an adequate solution to the problem, and perhaps adding a timeout. It's fairly common to run a job to run migrations before rolling out a deployment.