-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: set default timeouts #4066
Conversation
cd0c584
to
0760794
Compare
my opinions
why? I think these are plenty long enough
I'm thinking between 3 to 5 min, don't see how a normal deploy could take longer than that
Nah, I don't think so. User's will see the timeout if they ever run into it and most probably won't unless they're doing something wrong or very special |
@Orzelius thanks for the feedback! I've been thinking about this again and have realized that warning messages can be too annoying for users. It's better to emphasize that all actions have timeouts in the release notes. Anyway, it is a breaking change and will be announced accordingly. On the default values, I'm not sure about deployments. The deployment time depends on the deployment policy and the number of app instances to be deployed. Theoretically, every action can take a long time. But, of course, the default values should be something sane :) Update. We do have timeouts for Deploy action, but not for all types of those. The timeout settings of Deploy actions reside in the type-specific |
@@ -97,7 +100,7 @@ export interface ExecDeployActionSpec extends CommonKeys { | |||
cleanupCommand?: string[] | |||
deployCommand: string[] | |||
statusCommand?: string[] | |||
timeout?: number | |||
timeout: number |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@edvald it looks like this value is never used. Removing this and its initialization in the converter brings no compilation errors.
The timeout value is never passed to the runPersistent
function which, in turn, does not seem to support timeouts.
There is external logic on the runPersistent
caller's side that relies on the statusTimeout
and statusCommand
. Do we still need this timeout
field?
There are some test failures, I'll fix those soon. |
da5817f
to
0e32ab5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Mostly had one comment there.
@@ -32,6 +33,7 @@ export const k8sContainerRun: RunActionHandler<"run", ContainerRunAction> = asyn | |||
dropCapabilities, | |||
} = action.getSpec() | |||
|
|||
const timeout = action.getConfig("timeout") || DEFAULT_RUN_TIMEOUT_SEC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the || DEFAULT_RUN_TIMEOUT_SEC
part unnecessary, since the timeout value is always set on the action?
The same question applies elsewhere in this PR where the default value is used as a fallback in plugin code (where it shouldn't be necessary, i.e. the default value should already be set on the action).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thsig, yes, that's correct. We can safely declare the timeout
field as non-optional in BuildActionConfig
, RunActionConfig
, and TestActionConfig
.
it would be also nice to pull that field to the base class BaseActionConfig
, and make it mandatory in DeployActionConfig
too.
c2401c1
to
35a343e
Compare
9bb240c
to
209d501
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me as far as I can tell, good work! 🎉
Constant `DEFAULT_BUILD_TIMEOUT` was used only in tests, and was a duplicate of `DEFAULT_BUILD_TIMEOUT_SEC`.
The version was changed because the `timeout` field was set in the config.
Now timeout is always defined in the root-level config and in each run/task spec.
Use the same set pattern as in the Test action. The non-null timeout value is set in the downstream functions, so there is no harm. All action are planned to have non-null timeout, so the default value here will be omitted in the later commits.
It's always set in the caller-side functions.
Non-optional value is always set from outside.
What this PR does / why we need it:
Open questions:
exec
Deploys). -> This can be discussed in the code review round.timeout
in the action type-specificspec
field. We might need to pull it up to the root config level like in Builds, Runs, and Deploys. That will be done in a separate PR.It might be a good idea to emit a warning message about the default action timeouts on Garden startup.Which issue(s) this PR fixes:
Closes #3516
Special notes for your reviewer:
See individual commits for details. Squash the commits before the merge.