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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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