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
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
Both the :mod:`pkg.removed <salt.states.pkg.removed>` and :mod:`pkg.purged
|
|
|
|
<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
|
|
|
|
of a specific value. However, please note that if a cron job already has a
|
|
|
|
numeric value (in other words, not ``*``), changing the value to ``random``
|
|
|
|
will not modify this field in the crontab. Otherwise, the value would be
|
|
|
|
modified every time the state was applied.
|
|
|
|
|