2013-06-18 06:46:14 +00:00
|
|
|
=========================
|
|
|
|
Salt 0.16.0 Release Notes
|
|
|
|
=========================
|
|
|
|
|
|
|
|
The 0.16.0 release is an exciting one, with new features in master redundancy,
|
2013-06-18 22:01:57 +00:00
|
|
|
and a new, powerful requisite.
|
2013-06-18 06:46:14 +00:00
|
|
|
|
|
|
|
Major Features
|
|
|
|
==============
|
|
|
|
|
|
|
|
Multi-Master
|
|
|
|
------------
|
|
|
|
|
|
|
|
This new capability allows for a minion to be actively connected to multiple
|
2013-06-18 22:01:57 +00:00
|
|
|
salt masters at the same time. This allows for multiple masters to send out commands
|
2013-06-18 06:46:14 +00:00
|
|
|
to minions and for minions to automatically reconnect to masters that have gone
|
|
|
|
down.
|
|
|
|
|
|
|
|
Prereq, the New Requisite
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
The new `prereq` requisite is very powerful! It allows for states to execute
|
|
|
|
based on a state that is expected to make changes in the future. This allows
|
|
|
|
for a change on the system to be preempted by another execution. A good example
|
|
|
|
is needing to shut down a service before modifying files associated with it,
|
2013-06-18 22:01:57 +00:00
|
|
|
allowing, for instance, a webserver to be shut down allowing a load balancer to
|
|
|
|
stop sending requests while server side code is updated. In this case, the
|
2013-06-18 06:46:14 +00:00
|
|
|
prereq will only run if changes are expected to happen in the prerequired
|
|
|
|
state, and the prerequired state will always run after the prereq state and
|
|
|
|
only if the prereq state succeeds.
|
2013-06-19 00:46:48 +00:00
|
|
|
|
|
|
|
Muliple Targets for pkg.removed, pkg.purged States
|
|
|
|
--------------------------------------------------
|
|
|
|
|
2013-06-19 00:50:33 +00:00
|
|
|
Both :mod:`pkg.removed <salt.states.pkg.removed>` and :mod:`pkg.purged
|
2013-06-19 00:46:48 +00:00
|
|
|
<salt.states.pkg.purged>` now support the ``pkgs`` argument, which allow for
|
|
|
|
multiple packages to be targeted in a single state. This, as in
|
|
|
|
:mod:`pkg.installed <salt.states.pkg.installed>`, helps speed up these
|
|
|
|
states by reducing the number of times that the package management tools (apt,
|
|
|
|
yum, etc.) need to be run.
|
|
|
|
|
|
|
|
Random Times in Cron States
|
|
|
|
---------------------------
|
|
|
|
|
|
|
|
The temporal parameters in :mod:`cron.present <salt.states.cron.present>`
|
|
|
|
states (minute, hour, etc.) can now be randomized by using ``random`` instead
|
2013-06-19 15:26:04 +00:00
|
|
|
of a specific value. For example, by using the ``random`` keyword in the
|
|
|
|
``minute`` parameter of a cron state, the same cron job can be pushed to
|
|
|
|
hundreds or thousands of hosts, and they would each use a randomly-generated
|
|
|
|
minute. This can be helpful when the cron job accesses a network resource, and
|
|
|
|
it is not desirable for all hosts to run the job concurrently.
|
2013-06-19 00:46:48 +00:00
|
|
|
|
2013-06-19 15:26:04 +00:00
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
/path/to/cron/script:
|
|
|
|
cron.present:
|
|
|
|
- user: root
|
|
|
|
- minute: random
|
|
|
|
- hour: 2
|
|
|
|
|
|
|
|
Since Salt assumes a value of ``*`` for unspecified temporal parameters, adding
|
|
|
|
a parameter to the state and setting it to ``random`` will change that value
|
|
|
|
from ``*`` to a randomized numeric value. However, if the cron entry contains a
|
|
|
|
numeric value on the minion, then using the ``random`` keyword will not modify
|
|
|
|
this field.
|