Add flag to run scheduled task on deploy #1515
Conversation
Adds a field in the deploy, `runImmediately`, which takes a `SingularityRunNowRequest`. If that field is present, then the scheduled task (or on-demand task) will be run immediately after deploying.
|
A few things on this one:
|
Provide more validation for the run immediately request. Also centralizes the validation of both the run-now request and the run-immediately-on-deploy request in the SingularityValidator class. Also also also adds a few more tests in Singularity Validator.
|
+1 for consolidating in the validator. Let's fix the merge conflicts and give this a try in staging |
Catch missing cases for running once-off tasks. In particular, I had assummed `request.isOneOff` included both on-demand and run-once tasks, which it doesn't.
| SingularityRunNowRequest runNowRequest = maybeRunNowRequest.get(); | ||
| pendingType = PendingType.ONEOFF; | ||
| runId = runNowRequest.getRunId().or(Optional.of(UUID.randomUUID().toString())); | ||
| message = runNowRequest.getMessage() |
There was a problem hiding this comment.
might be going a bit line-break happy here/above/below in this method ;) can get a bit hard to read
There was a problem hiding this comment.
Just couldn't wait to get started with immutables c:
| pendingDeploy, | ||
| deployResult, | ||
| deploy.get().getRunImmediately()); | ||
| if (maybePendingRequest.isPresent()) { |
There was a problem hiding this comment.
for this and the one below. We should always make sure some pending request gets enqueued for a !deployable && !oneOff case. If it doesn't get enqueued it's possible we could miss scheduling the next run of a cron or something like that.
| throw badRequest("Can not request an immediate run of a non-scheduled / always running request (%s)", request); | ||
| } | ||
|
|
||
| boolean canRunImmediately = |
There was a problem hiding this comment.
do we want to validate this at the time the deploy is enqueued? We re-check similar conditions at the time the pending request is created when the deploy finishes, and the data could have changed by then. Checking here also causes a few extra zk calls (activeTaskIds/pendingTaskIds) that could possibly be hit on the non-leader instance
Respond to PR comments. In particular - Style change: reduce the number of line breaks in method calls - Don't validate task count on enqueue; defer it to the deploy is going to be run - Guaranteed that _something_ will be deployed, even when a task couldn't be run.
Adds a field in the deploy,
runImmediately, which takes aSingularityRunNowRequest. If that field is present, then the scheduledtask (or on-demand task) will be run immediately after deploying.
/cc @ssalinas