Here is the draft PR with default timeout values: ...
# 💻|contributing
c
Here is the draft PR with default timeout values: https://github.com/garden-io/garden/pull/4066 I've created a list of to-be-discussed questions in the PR's description. cc @swift-garage-61180 @calm-family-29323 @alert-helicopter-61082 @big-spring-14945
Let's discuss in the thread
Does it make sense to have
timeout
config for
configmap
and
persistentvlumeclaim
types of
Deploy
action? Both deploy handlers delegate to k8s deploy handler (function
kubernetesDeploy
) that supports timeouts. I'm not sure if this is a real-life scenario when PVC or ConfigMap creation can take too long. Wdyt? cc @swift-garage-61180 @calm-family-29323 @alert-helicopter-61082
c
I think it makes sense for PVC-s as the they can definitely get stuck in the deploy state. Not sure about the configmaps though, but I don't think it can hurt
s
They could time out e.g. when there are network problems or an auth issue. There's almost always a way for deploys to time out, one way or another.
So IMHO it makes sense for timeouts to be a framework-native primitive. Doesn't seem particularly urgent, though—there's more pressing stuff for us to work on in Core.
a
Feels like basically every action kind should have a native timeout field. I forget why exactly it wasn't made native for all of them to begin with. I do think we actually have to consider this quickly because we may need to move some fields around (basically
spec.timeout
->
timeout
wherever
spec.timeout
is currently defined by the action type).
c
Well, I can avoid these changes in https://github.com/garden-io/garden/pull/4066
basically, the PR above already sets default values for timeouts. But, in TS interfaces we still have to keep the
timeout
field declaration as optional.
We can do the
spec.timeout
->
timeout
refactoring in a separate PR. But still in 0.13, right? Let's make a decision on this. We can discuss it in the Core planning on Monday too.
4 Views