You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current meaning of a batch job is to be "enabled" from the moment the job is run, i.e. "now". The use case for this is primarily in context of periodic (cron) jobs, but can also be thought of for regular batch jobs.
I propose, two new fields for the job which can be used to activate (or enable) the batch job from a future date and also be able to govern when the job ends, i.e. not run past a certain time.
Current stanza:
type="batch"periodic {
cron="*/15 * * * * *"
}
Proposed solution:
type="batch"start_at="2022-MAY-04"# timestamp can be a standard format, strings used here only for sake of clarity.end_at="2022-JUNE-04"periodic {
cron="*/15 * * * * *"
}
Use-cases
The use case is to be able to have a job be "run" now, but not activate (i.e. start) until a future date.
Attempted Solutions
For a time spec which repeats within a day, this can be achieved by submitting three separate jobs (but seems hacky):
from the specified date to end of the month.
from the subsequent month to the end of the year.
from the subsequent year to the end-of-time.
Submit two jobs, one which runs at the specific time (2022-MAY-04) which in turn submits the actual simple periodic job. (this too seems hacky).
A third job can be scheduled to run on 2022-JUNE-04, which does a stop -purge on the first job.
The text was updated successfully, but these errors were encountered:
I think this (and #2395) could also be related to hashicorp/nomad-autoscaler#448, where this behaviour could achieved using the Autoscaler. I will put this for further discussion and triage.
Anyone else interested in this feature please give it a 👍 to help us gauge interest 🙂
I would love this sort of functionality. At SeatGeek, we have jobs that need to be run during certain seasons - say, run a report for all NFL purchases during the season - and then don't need to run afterwards. Currently, we delete the jobs from Nomad, but then need to remember to re-add it. Would be great to be able to have that handled in the registered Nomad job itself.
Not sure what the format would/should be - dates are fine, but potentially there is a more flexible format for periods of time - but it should probably be inside of the periodic stanza and not at the job level.
Proposal
The current meaning of a
batch
job is to be "enabled" from the moment the job isrun
, i.e. "now".The use case for this is primarily in context of
periodic
(cron
) jobs, but can also be thought of for regularbatch
jobs.I propose, two new fields for the
job
which can be used to activate (or enable) thebatch
job from a future date and also be able to govern when the job ends, i.e. not run past a certain time.Current stanza:
Proposed solution:
Use-cases
The use case is to be able to have a job be "run" now, but not activate (i.e. start) until a future date.
Attempted Solutions
2022-MAY-04
) which in turn submits the actual simple periodic job. (this too seems hacky).A third job can be scheduled to run on
2022-JUNE-04
, which does astop -purge
on the first job.The text was updated successfully, but these errors were encountered: