Forbid health checks longer than kill time #1498
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Singularity is configured to automatically kill tasks which are nonresponsive for a certain amount of time after startup (`killAfterTasksDoNotRunDefaultSeconds`, set in the config file). If a task is configured such that it won't start accepting healthchecks for longer than that interval, Singularity will just kill it off, without ever sending health checks. This makes it so that that task configuration will be rejected ahead of time by Singularity.
ssalinas
reviewed
Apr 10, 2017
| int startUpDelay = deploy.getHealthcheck().get().getStartupDelaySeconds().get(); | ||
|
|
||
| checkBadRequest(startUpDelay < defaultKillAfterNotHealthySeconds, | ||
| String.format("Health check startup delay time must be less than kill after wait time %s (was %s)", defaultKillAfterNotHealthySeconds, startUpDelay)); |
There was a problem hiding this comment.
probably not as important for the user to know that we call it the 'kill after wait time'. Maybe just Health check startup delay time must be less than {time} seconds (was {time} seconds)
Other than that LGTM
There were two fields on the new deploy form that were labeled "HC startup delay." This renames one of them to "HC startup timeout." They bot functioned correctly and pointed to the the correct fields in the deploy JSON; the label on one of them was just mixed up.
Was previously giving perhaps too much information to the user (ie, that the upper limit was coming from how long we would wait to kill a task that didn't appear to be starting). Not it just reflects the maximum amount of time that you are allowed to put down.
matush-v
reviewed
Apr 12, 2017
|
|
||
| WebApplicationException exn = (WebApplicationException) catchThrowable(() -> validator.checkDeploy(request, deploy)); | ||
| assertThat((String) exn.getResponse().getEntity()) | ||
| .contains("Health check startup delay"); |
There was a problem hiding this comment.
whoa, this catch is very cool
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Singularity is configured to automatically kill tasks which are
nonresponsive for a certain amount of time after startup
(
killAfterTasksDoNotRunDefaultSeconds, set in the config file). If atask is configured such that it won't start accepting healthchecks for
longer than that interval, Singularity will just kill it off, without
ever sending health checks. This makes it so that that task
configuration will be rejected ahead of time by Singularity.