Here is the draft PR with default timeout values https githu

Question

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>

curved-intern-91221 · Answer

Let s discuss in the thread

curved-intern-91221 · Answer

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>

calm-family-29323 · Answer

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

swift-garage-61180 · Answer

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

swift-garage-61180 · Answer

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

alert-helicopter-61082 · Answer

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

curved-intern-91221 · Answer

Well I can avoid these changes in https github com garden io garden pull 4066

curved-intern-91221 · Answer

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

curved-intern-91221 · Answer

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