mirror of
https://github.com/saltstack/salt.git
synced 2025-04-17 10:10:20 +00:00
[DOC] Add doc page reference for schedule util module
This commit is contained in:
Denys Havrysh
parent
1bd260a663
commit
da5e580f8c
2 changed files with 28 additions and 337 deletions
|
|
@ -211,6 +211,28 @@ localtime.
|
|||
This will schedule the command: ``state.sls httpd test=True`` at 5:00 PM on
|
||||
Monday, Wednesday and Friday, and 3:00 PM on Tuesday and Thursday.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
when:
|
||||
- 'tea time'
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
whens:
|
||||
tea time: 1:40pm
|
||||
deployment time: Friday 5:00pm
|
||||
|
||||
The Salt scheduler also allows custom phrases to be used for the `when`
|
||||
parameter. These `whens` can be stored as either pillar values or
|
||||
grain values.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
|
|
|
|||
|
|
@ -1,344 +1,13 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
|
||||
# See doc/topics/jobs/index.rst
|
||||
'''
|
||||
Scheduling routines are located here. To activate the scheduler make the
|
||||
schedule option available to the master or minion configurations (master config
|
||||
file or for the minion via config or pillar)
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
seconds: 3600
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
|
||||
This will schedule the command: ``state.sls httpd test=True`` every 3600 seconds
|
||||
(every hour).
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
seconds: 3600
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
splay: 15
|
||||
|
||||
This will schedule the command: ``state.sls httpd test=True`` every 3600 seconds
|
||||
(every hour) splaying the time between 0 and 15 seconds.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
seconds: 3600
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
splay:
|
||||
start: 10
|
||||
end: 15
|
||||
|
||||
This will schedule the command: ``state.sls httpd test=True`` every 3600 seconds
|
||||
(every hour) splaying the time between 10 and 15 seconds.
|
||||
|
||||
.. versionadded:: 2014.7.0
|
||||
|
||||
Frequency of jobs can also be specified using date strings supported by
|
||||
the Python ``dateutil`` library. This requires the Python ``dateutil`` library
|
||||
to be installed.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
when: 5:00pm
|
||||
|
||||
This will schedule the command: ``state.sls httpd test=True`` at 5:00 PM minion
|
||||
localtime.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
when:
|
||||
- Monday 5:00pm
|
||||
- Tuesday 3:00pm
|
||||
- Wednesday 5:00pm
|
||||
- Thursday 3:00pm
|
||||
- Friday 5:00pm
|
||||
|
||||
This will schedule the command: ``state.sls httpd test=True`` at 5:00 PM on
|
||||
Monday, Wednesday and Friday, and 3:00 PM on Tuesday and Thursday.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
when:
|
||||
- 'tea time'
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
whens:
|
||||
tea time: 1:40pm
|
||||
deployment time: Friday 5:00pm
|
||||
|
||||
The Salt scheduler also allows custom phrases to be used for the `when`
|
||||
parameter. These `whens` can be stored as either pillar values or
|
||||
grain values.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
seconds: 3600
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
range:
|
||||
start: 8:00am
|
||||
end: 5:00pm
|
||||
|
||||
This will schedule the command: ``state.sls httpd test=True`` every 3600 seconds
|
||||
(every hour) between the hours of 8:00 AM and 5:00 PM. The range parameter must
|
||||
be a dictionary with the date strings using the ``dateutil`` format.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
seconds: 3600
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
range:
|
||||
invert: True
|
||||
start: 8:00am
|
||||
end: 5:00pm
|
||||
|
||||
Using the invert option for range, this will schedule the command
|
||||
``state.sls httpd test=True`` every 3600 seconds (every hour) until the current
|
||||
time is between the hours of 8:00 AM and 5:00 PM. The range parameter must be
|
||||
a dictionary with the date strings using the ``dateutil`` format.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: pkg.install
|
||||
kwargs:
|
||||
pkgs: [{'bar': '>1.2.3'}]
|
||||
refresh: true
|
||||
once: '2016-01-07T14:30:00'
|
||||
|
||||
This will schedule the function ``pkg.install`` to be executed once at the
|
||||
specified time. The schedule entry ``job1`` will not be removed after the job
|
||||
completes, therefore use ``schedule.delete`` to manually remove it afterwards.
|
||||
|
||||
The default date format is ISO 8601 but can be overridden by also specifying the
|
||||
``once_fmt`` option, like this:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: test.ping
|
||||
once: 2015-04-22T20:21:00
|
||||
once_fmt: '%Y-%m-%dT%H:%M:%S'
|
||||
|
||||
.. versionadded:: 2014.7.0
|
||||
|
||||
The scheduler also supports ensuring that there are no more than N copies of
|
||||
a particular routine running. Use this for jobs that may be long-running
|
||||
and could step on each other or pile up in case of infrastructure outage.
|
||||
|
||||
The default for ``maxrunning`` is 1.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
long_running_job:
|
||||
function: big_file_transfer
|
||||
jid_include: True
|
||||
maxrunning: 1
|
||||
|
||||
.. versionadded:: 2014.7.0
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
cron: '*/15 * * * *'
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
|
||||
The scheduler also supports scheduling jobs using a cron like format.
|
||||
This requires the Python ``croniter`` library.
|
||||
|
||||
.. versionadded:: 2015.5.0
|
||||
|
||||
By default, data about jobs runs from the Salt scheduler is returned to the
|
||||
master. Setting the ``return_job`` parameter to False will prevent the data
|
||||
from being sent back to the Salt master.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: scheduled_job_function
|
||||
return_job: False
|
||||
|
||||
.. versionadded:: 2015.5.0
|
||||
|
||||
It can be useful to include specific data to differentiate a job from other
|
||||
jobs. Using the metadata parameter special values can be associated with
|
||||
a scheduled job. These values are not used in the execution of the job,
|
||||
but can be used to search for specific jobs later if combined with the
|
||||
``return_job`` parameter. The metadata parameter must be specified as a
|
||||
dictionary, othewise it will be ignored.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: scheduled_job_function
|
||||
metadata:
|
||||
foo: bar
|
||||
|
||||
.. versionadded:: 2015.5.0
|
||||
|
||||
By default any job scheduled based on the startup time of the minion will run
|
||||
the scheduled job when the minion starts up. Sometimes this is not the desired
|
||||
situation. Using the ``run_on_start`` parameter set to ``False`` will cause the
|
||||
scheduler to skip this first run and wait until the next scheduled run:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
seconds: 3600
|
||||
run_on_start: False
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
|
||||
.. versionadded:: 2015.8.0
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
seconds: 15
|
||||
until: '12/31/2015 11:59pm'
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
|
||||
Using the until argument, the Salt scheduler allows you to specify
|
||||
an end time for a scheduled job. If this argument is specified, jobs
|
||||
will not run once the specified time has passed. Time should be specified
|
||||
in a format supported by the ``dateutil`` library.
|
||||
This requires the Python ``dateutil`` library to be installed.
|
||||
|
||||
.. versionadded:: 2015.8.0
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: state.sls
|
||||
seconds: 15
|
||||
after: '12/31/2015 11:59pm'
|
||||
args:
|
||||
- httpd
|
||||
kwargs:
|
||||
test: True
|
||||
|
||||
Using the after argument, the Salt scheduler allows you to specify
|
||||
an start time for a scheduled job. If this argument is specified, jobs
|
||||
will not run until the specified time has passed. Time should be specified
|
||||
in a format supported by the ``dateutil`` library.
|
||||
This requires the Python ``dateutil`` library to be installed.
|
||||
|
||||
The scheduler also supports ensuring that there are no more than N copies of
|
||||
a particular routine running. Use this for jobs that may be long-running
|
||||
and could step on each other or pile up in case of infrastructure outage.
|
||||
|
||||
The default for maxrunning is 1.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
schedule:
|
||||
long_running_job:
|
||||
function: big_file_transfer
|
||||
jid_include: True
|
||||
maxrunning: 1
|
||||
|
||||
By default, data about jobs runs from the Salt scheduler is returned to the
|
||||
master. Setting the ``return_job`` parameter to False will prevent the data
|
||||
from being sent back to the Salt master.
|
||||
|
||||
.. versionadded:: 2015.5.0
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: scheduled_job_function
|
||||
return_job: False
|
||||
|
||||
Setting the ``return_job`` parameter to 'nocache' prevents the salt master
|
||||
from storing the job in the master cache. Still, an event is fired on the
|
||||
master event bus in the form 'salt/job/nocache/ret/myminion'.
|
||||
|
||||
It can be useful to include specific data to differentiate a job from other
|
||||
jobs. Using the metadata parameter special values can be associated with
|
||||
a scheduled job. These values are not used in the execution of the job,
|
||||
but can be used to search for specific jobs later if combined with the
|
||||
return_job parameter. The metadata parameter must be specified as a
|
||||
dictionary, othewise it will be ignored.
|
||||
|
||||
.. versionadded:: 2015.5.0
|
||||
|
||||
schedule:
|
||||
job1:
|
||||
function: scheduled_job_function
|
||||
metadata:
|
||||
foo: bar
|
||||
``schedule`` option available to the master or minion configurations (master
|
||||
config file or for the minion via config or pillar).
|
||||
|
||||
Detailed tutorial about scheduling jobs can be found :ref:`here
|
||||
<scheduling-jobs>`.
|
||||
'''
|
||||
|
||||
# Import python libs
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue