saltstack/salt
1
0
Fork 0
mirror of https://github.com/saltstack/salt.git synced 2025-04-17 10:10:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Merge branch '2015.8' into '2016.3'

Browse source 
Conflicts:
  - doc/ref/states/compiler_ordering.rst
  - doc/topics/installation/suse.rst
  - doc/topics/jobs/schedule.rst
  - doc/topics/targeting/grains.rst
  - doc/topics/tutorials/preseed_key.rst
  - doc/topics/tutorials/states_pt5.rst
  - pkg/suse/use-forking-daemon.patch
  - salt/minion.py
  - salt/modules/pacman.py
  - salt/modules/state.py
  - salt/modules/yumpkg.py
This commit is contained in:
rallytime 2016-03-25 11:47:16 -06:00
commit f6d9cdc633
62 changed files with 698 additions and 515 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/conf.py
View file

@ -172,8 +172,8 @@ project = 'Salt'
copyright = '2016 SaltStack, Inc.'
version = salt.version.__version__
latest_release = '2015.8.7' # latest release
previous_release = '2015.5.9' # latest release from previous branch
latest_release = '2015.8.8' # latest release
previous_release = '2015.5.10' # latest release from previous branch
previous_release_dir = '2015.5' # path on web server for previous branch
next_release = '2016.3.0' # latest release from previous branch
next_release_dir = '2016.3' # path on web server for previous branch

10
doc/faq.rst
View file

@ -38,8 +38,8 @@ I'm seeing weird behavior (including but not limited to packages not installing
This is often caused by SELinux. Try disabling SELinux or putting it in
permissive mode and see if the weird behavior goes away.
My script runs every time I run a *state.highstate*. Why?
---------------------------------------------------------
My script runs every time I run a *state.apply*. Why?
-----------------------------------------------------
You are probably using :mod:`cmd.run <salt.states.cmd.run>` rather than
:mod:`cmd.wait <salt.states.cmd.wait>`. A :mod:`cmd.wait
@ -134,11 +134,11 @@ should be opened on our tracker_, with the following information:
Why aren't my custom modules/states/etc. available on my Minions?
-----------------------------------------------------------------
Custom modules are only synced to Minions when :mod:`state.highstate
<salt.modules.state.highstate>`, :mod:`saltutil.sync_modules
Custom modules are only synced to Minions when :mod:`state.apply
<salt.modules.state.apply_>`, :mod:`saltutil.sync_modules
<salt.modules.saltutil.sync_modules>`, or :mod:`saltutil.sync_all
<salt.modules.saltutil.sync_all>` is run. Similarly, custom states are only
synced to Minions when :mod:`state.highstate <salt.modules.state.highstate>`,
synced to Minions when :mod:`state.apply <salt.modules.state.apply_>`,
:mod:`saltutil.sync_states <salt.modules.saltutil.sync_states>`, or
:mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>` is run.

11
doc/ref/cli/_includes/target-selection-ssh.rst Normal file
View file

@ -0,0 +1,11 @@
Target Selection
----------------
The default matching that Salt utilizes is shell-style globbing around the
minion id. See https://docs.python.org/2/library/fnmatch.html#module-fnmatch.
.. option:: -E, --pcre
The target expression will be interpreted as a PCRE regular expression
rather than a shell glob.

3
doc/ref/cli/_includes/target-selection.rst
View file

@ -1,6 +1,9 @@
Target Selection
----------------
The default matching that Salt utilizes is shell-style globbing around the
minion id. See https://docs.python.org/2/library/fnmatch.html#module-fnmatch.
.. option:: -E, --pcre
The target expression will be interpreted as a PCRE regular expression

2
doc/ref/cli/salt-ssh.rst
View file

@ -79,7 +79,7 @@ Options
.. include:: _includes/common-options.rst
.. include:: _includes/target-selection.rst
.. include:: _includes/target-selection-ssh.rst
.. include:: _includes/logging-options.rst
.. |logfile| replace:: /var/log/salt/ssh

2
doc/ref/clients/index.rst
View file

@ -72,6 +72,8 @@ Each module type has a corresponding loader function.
Salt's Client Interfaces
========================
.. _local-client:
LocalClient
-----------

6
doc/ref/configuration/minion.rst
View file

@ -331,10 +331,10 @@ Verify and set permissions on configuration directories at startup.
.. note::
When marked as True the verify_env option requires WRITE access to the
When set to ``True`` the verify_env option requires WRITE access to the
configuration directory (/etc/salt/). In certain situations such as
mounting /etc/salt/ as read-only for templating this will create a
stack trace when state.highstate is called.
mounting /etc/salt/ as read-only for templating this will create a stack
trace when :py:func:`state.apply <salt.modules.state.apply_>` is called.
.. conf_minion:: cache_jobs

2
doc/ref/modules/index.rst
View file

@ -20,7 +20,7 @@ default this is ``/srv/salt/_modules`` on Linux systems.
Modules placed in ``_modules/`` will be synced to the minions when any of the following
Salt functions are called:
* :mod:`state.highstate <salt.modules.state.highstate>`
* :mod:`state.apply <salt.modules.state.apply_>`
* :mod:`saltutil.sync_modules <salt.modules.saltutil.sync_modules>`
* :mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>`

7
doc/ref/renderers/index.rst
View file

@ -121,11 +121,10 @@ Custom renderers must be placed in a ``_renderers`` directory within the
:conf_master:`file_roots` specified by the master config file.
Custom renderers are distributed when any of the following are run:
:mod:`state.highstate <salt.modules.state.highstate>`
:mod:`saltutil.sync_renderers <salt.modules.saltutil.sync_renderers>`
:mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>`
- :py:func:`state.apply <salt.modules.state.apply_>`
- :py:func:`saltutil.sync_renderers <salt.modules.saltutil.sync_renderers>`
- :py:func:`saltutil.sync_all <salt.modules.saltutil.sync_all>`
Any custom renderers which have been synced to a minion, that are named the
same as one of Salt's default set of renderers, will take the place of the

7
doc/ref/returners/index.rst
View file

@ -289,11 +289,10 @@ Place custom returners in a ``_returners`` directory within the
:conf_master:`file_roots` specified by the master config file.
Custom returners are distributed when any of the following are called:
:mod:`state.highstate <salt.modules.state.highstate>`
:mod:`saltutil.sync_returners <salt.modules.saltutil.sync_returners>`
:mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>`
- :mod:`state.apply <salt.modules.state.apply_>`
- :mod:`saltutil.sync_returners <salt.modules.saltutil.sync_returners>`
- :mod:`saltutil.sync_all <salt.modules.saltutil.sync_all>`
Any custom returners which have been synced to a minion that are named the
same as one of Salt's default set of returners will take the place of the

2
doc/ref/states/compiler_ordering.rst
View file

@ -226,7 +226,7 @@ In the following case:
include:
- qux
In the above case if ``state.sls foo`` were called then the formulas will be
In the above case if ``state.apply foo`` were called then the formulas will be
loaded in the following order:
1. quo

12
doc/ref/states/highstate.rst
View file

@ -34,7 +34,7 @@ Include declaration
Defines a list of :ref:`module-reference` strings to include in this ``SLS``.
Occurs only in the top level of the highstate structure.
Occurs only in the top level of the SLS data structure.
Example:
@ -58,10 +58,10 @@ file ``salt://edit/vim.sls``.
ID declaration
--------------
Defines an individual highstate component. Always references a value of a
dictionary containing keys referencing :ref:`state-declaration` and
:ref:`requisite-declaration`. Can be overridden by a :ref:`name-declaration` or
a :ref:`names-declaration`.
Defines an individual :ref:`highstate <running-highstate>` component. Always
references a value of a dictionary containing keys referencing
:ref:`state-declaration` and :ref:`requisite-declaration`. Can be overridden by
a :ref:`name-declaration` or a :ref:`names-declaration`.
Occurs on the top level or under the :ref:`extend-declaration`.
@ -72,7 +72,7 @@ ID declarations with the same name will be ignored.
.. note:: Naming gotchas
In Salt versions earlier than 0.9.7, ID declarations containing dots would
result in unpredictable highstate output.
result in unpredictable output.
.. _extend-declaration:

7
doc/ref/states/include.rst
View file

@ -74,10 +74,10 @@ another SLS file or a specific id. The component is excluded after the
high data has been compiled, so nothing should be able to override an
exclude.
Since the exclude can remove an id or an SLS the type of component to exclude
Since the exclude can remove an id or an sls the type of component to exclude
needs to be defined. An exclude statement that verifies that the running
highstate does not contain the ``http`` SLS and the ``/etc/vimrc`` id would
look like this:
:ref:`highstate <running-highstate>` does not contain the ``http`` sls and the
``/etc/vimrc`` id would look like this:
.. code-block:: yaml
@ -89,3 +89,4 @@ look like this:
The current state processing flow checks for duplicate IDs before
processing excludes. An error occurs if duplicate IDs are present even if
one of the IDs is targeted by an ``exclude``.

4
doc/ref/states/index.rst
View file

@ -213,7 +213,7 @@ earlier, requires `pip`_ to be installed system-wide. Let's execute this state:
.. code-block:: bash
salt-call state.sls pep8
salt-call state.apply pep8
The execution output would be something like:
@ -292,7 +292,7 @@ Let's run it, once:
.. code-block:: bash
salt-call state.sls pep8
salt-call state.apply pep8
The output is:

14
doc/ref/states/layers.rst
View file

@ -46,7 +46,7 @@ Low State
=========
The `Low State` layer is the list of low chunks "evaluated" in order. To see
what the low state looks like for a highstate, run:
what the low state looks like for a :ref:`highstate <running-highstate>`, run:
.. code-block:: bash
@ -96,11 +96,12 @@ The SLS layer can be called directly to execute individual sls formulas.
in a much more dynamic way by combining pillar and other sources, and the
SLS can be dynamically generated.
To call a single SLS formula named ``edit.vim``, execute ``state.sls``:
To call a single SLS formula named ``edit.vim``, execute :py:func:`state.apply
<salt.modules.state.apply_>` and pass ``edit.vim`` as an argument:
.. code-block:: bash
salt '*' state.sls edit.vim
salt '*' state.apply edit.vim
.. _state-layers-highstate:
@ -116,11 +117,12 @@ assigned from the master without needing to execute or configure anything on
the target minion. This also means that the minion can independently retrieve
information about its complete configuration from the master.
To execute the High State call ``state.highstate``:
To execute the :ref:`highstate <running-highstate>` use :py:func:`state.apply
<salt.modules.state.apply_>`:
.. code-block:: bash
salt '*' state.highstate
salt '*' state.apply
.. _state-layers-orchestrate:
@ -131,4 +133,4 @@ The orchestrate layer expresses the highest functional layer of Salt's automated
logic systems. The Overstate allows for stateful and functional orchestration
of routines from the master. The orchestrate defines in data execution stages
which minions should execute states, or functions, and in what order using
requisite logic.
requisite logic.

68
doc/ref/states/requisites.rst
View file

@ -4,40 +4,6 @@
Requisites and Other Global State Arguments
===========================================
.. _requisites-fire-event:
Fire Event Notifications
========================
.. versionadded:: 2015.8.0
The `fire_event` option in a state will cause the minion to send an event to
the Salt Master upon completion of that individual state.
The following example will cause the minion to send an event to the Salt Master
with a tag of `salt/state_result/20150505121517276431/dasalt/nano` and the
result of the state will be the data field of the event. Notice that the `name`
of the state gets added to the tag.
.. code-block:: yaml
nano_stuff:
pkg.installed:
- name: nano
- fire_event: True
In the following example instead of setting `fire_event` to `True`,
`fire_event` is set to an arbitrary string, which will cause the event to be
sent with this tag:
`salt/state_result/20150505121725642845/dasalt/custom/tag/nano/finished`
.. code-block:: yaml
nano_stuff:
pkg.installed:
- name: nano
- fire_event: custom/tag/nano/finished
Requisites
==========
@ -525,6 +491,40 @@ Now the httpd server will only start if php or mod_python are first verified to
be installed. Thus allowing for a requisite to be defined "after the fact".
.. _requisites-fire-event:
Fire Event Notifications
========================
.. versionadded:: 2015.8.0
The `fire_event` option in a state will cause the minion to send an event to
the Salt Master upon completion of that individual state.
The following example will cause the minion to send an event to the Salt Master
with a tag of `salt/state_result/20150505121517276431/dasalt/nano` and the
result of the state will be the data field of the event. Notice that the `name`
of the state gets added to the tag.
.. code-block:: yaml
nano_stuff:
pkg.installed:
- name: nano
- fire_event: True
In the following example instead of setting `fire_event` to `True`,
`fire_event` is set to an arbitrary string, which will cause the event to be
sent with this tag:
`salt/state_result/20150505121725642845/dasalt/custom/tag/nano/finished`
.. code-block:: yaml
nano_stuff:
pkg.installed:
- name: nano
- fire_event: custom/tag/nano/finished
Altering States
===============

8
doc/ref/states/startup.rst
View file

@ -13,8 +13,8 @@ executed at startup. The options are `startup_states`, `sls_list`, and
The `startup_states` option can be passed one of a number of arguments to
define how to execute states. The available options are:
highstate
Execute ``state.highstate``
:ref:`highstate <running-highstate>`
Execute :py:func:`state.apply <salt.modules.state.apply_>`
sls
Read in the ``sls_list`` option and execute the named sls files
@ -26,8 +26,8 @@ top
Examples:
---------
Execute ``state.highstate`` when starting the minion:
Execute :py:func:`state.apply <salt.modules.state.apply_>` to run the
:ref:`highstate <running-highstate>` when starting the minion:
.. code-block:: yaml

10
doc/ref/states/testing.rst
View file

@ -11,8 +11,8 @@ interface can be invoked on any of the major state run functions:
.. code-block:: bash
salt '*' state.highstate test=True
salt '*' state.sls test=True
salt '*' state.apply test=True
salt '*' state.apply mysls test=True
salt '*' state.single test=True
The test run is mandated by adding the ``test=True`` option to the states. The
@ -28,6 +28,6 @@ states can still be run by calling test=False:
.. code-block:: bash
salt '*' state.highstate test=False
salt '*' state.sls test=False
salt '*' state.single test=False
salt '*' state.apply test=False
salt '*' state.apply mysls test=False
salt '*' state.single test=False

4
doc/ref/states/writing.rst
View file

@ -56,8 +56,8 @@ Using Custom State Modules
Place your custom state modules inside a ``_states`` directory within the
:conf_master:`file_roots` specified by the master config file. These custom
state modules can then be distributed in a number of ways. Custom state modules
are distributed when :mod:`state.highstate <salt.modules.state.highstate>` is
run, or by executing the :mod:`saltutil.sync_states
are distributed when :py:func:`state.apply <salt.modules.state.apply_>` is run,
or by executing the :mod:`saltutil.sync_states
<salt.modules.saltutil.sync_states>` or :mod:`saltutil.sync_all
<salt.modules.saltutil.sync_all>` functions.

9
doc/topics/cloud/deploy.rst
View file

@ -65,13 +65,14 @@ Post-Deploy Commands
====================
Once a minion has been deployed, it has the option to run a salt command.
Normally, this would be the state.highstate command, which would finish
provisioning the VM. Another common option is state.sls, or for just testing,
test.ping. This is configured in the main cloud config file:
Normally, this would be the :py:func:`state.apply <salt.modules.state.apply_>`,
which would finish provisioning the VM. Another common option (for testing) is
to use :py:func:`test.ping <salt.modules.test.ping>`. This is configured in the
main cloud config file:
.. code-block:: yaml
start_action: state.highstate
start_action: state.apply
This is currently considered to be experimental functionality, and may not work

30
doc/topics/cloud/reactor.rst
View file

@ -202,8 +202,8 @@ When Salt Cloud creates an instance, by default it will install the Salt Minion
onto the instance, along with any specified minion configuration, and
automatically accept that minion's keys on the master. One of the configuration
options that can be specified is ``startup_states``, which is commonly set to
``highstate``. This will tell the minion to immediately apply a highstate, as
soon as it is able to do so.
``highstate``. This will tell the minion to immediately apply a :ref:`highstate
<running-highstate>`, as soon as it is able to do so.
This can present a problem with some system images on some cloud hosts. For
instance, Salt Cloud can be configured to log in as either the ``root`` user, or
@ -213,12 +213,13 @@ log in (notably EC2, with their ``ec2-user`` login), most cloud hosts fall
back to ``root`` as the default login on all images, including for operating
systems (such as Ubuntu) which normally disallow remote ``root`` login.
For users of these operating systems, it is understandable that a highstate
would include configuration to block remote ``root`` logins again. However,
Salt Cloud may not have finished cleaning up its deployment files by the time
the minion process has started, and kicked off a highstate run. Users have
reported errors from Salt Cloud getting locked out while trying to clean up
after itself.
For users of these operating systems, it is understandable that a
:ref:`highstate <running-highstate>` would include configuration to block
remote ``root`` logins again. However, Salt Cloud may not have finished
cleaning up its deployment files by the time the minion process has started,
and kicked off a :ref:`highstate <running-highstate>` run. Users have reported
errors from Salt Cloud getting locked out while trying to clean up after
itself.
The goal of a startup state may be achieved using the Event Reactor. Because a
minion fires an event when it is able to receive commands, this event can
@ -231,17 +232,18 @@ the reactor system to the right ``sls`` file:
- 'salt/cloud/*/created':
- '/srv/reactor/startup_highstate.sls'
And the following ``sls`` file will start a highstate run on the target minion:
And the following ``sls`` file will start a :ref:`highstate
<running-highstate>` run on the target minion:
.. code-block:: yaml
# /srv/reactor/startup_highstate.sls
reactor_highstate:
cmd.state.highstate:
cmd.state.apply:
- tgt: {{ data['name'] }}
Because this event will not be fired until Salt Cloud has cleaned up after
itself, the highstate run will not step on Salt Cloud's toes. And because every
file on the minion is configurable, including ``/etc/salt/minion``, the
``startup_states`` can still be configured for future minion restarts, if
desired.
itself, the :ref:`highstate <running-highstate>` run will not step on
salt-cloud's toes. And because every file on the minion is configurable,
including ``/etc/salt/minion``, the ``startup_states`` can still be configured
for future minion restarts, if desired.

9
doc/topics/development/conventions/formulas.rst
View file

@ -367,7 +367,8 @@ variables or interact.
for :ref:`any of the alternate renderers <all-salt.renderers>` in Salt.)
* Highstate can be thought of as a human-friendly data structure; easy to write
and easy to read.
* Salt's state compiler validates the highstate and compiles it to low state.
* Salt's state compiler validates the :ref:`highstate <running-highstate>` and
compiles it to low state.
* Low state can be thought of as a machine-friendly data structure. It is a
list of dictionaries that each map directly to a function call.
* Salt's state system finally starts and executes on each "chunk" in the low
@ -1317,9 +1318,9 @@ structure can be performed by with the :py:func:`state.show_sls
salt '*' state.show_sls apache
Salt Formulas can then be tested by running each ``.sls`` file via
:py:func:`state.sls <salt.modules.state.sls>` and checking the output for the
success or failure of each state in the Formula. This should be done for each
supported platform.
:py:func:`state.apply <salt.modules.state.apply_>` and checking the output for
the success or failure of each state in the Formula. This should be done for
each supported platform.
.. ............................................................................

7
doc/topics/development/dunder_dictionaries.rst
View file

@ -91,8 +91,9 @@ During a state run the ``__context__`` dictionary persists across all states
that are run and then is destroyed when the state ends.
When running an execution module ``__context__`` persists across all module
executions until the modules are refreshed; such as when ``saltutils.sync_all``
or ``state.highstate`` are executed.
executions until the modules are refreshed; such as when
:py:func:`saltutil.sync_all <salt.modules.saltutil.sync_all>` or
:py:func:`state.apply <salt.modules.state.apply_>` are executed.
A great place to see how to use ``__context__`` is in the cp.py module in
salt/modules/cp.py. The fileclient authenticates with the master when it is
@ -109,4 +110,4 @@ each file. Here is an example from salt/modules/cp.py:
.. note:: Because __context__ may or may not have been destroyed, always be
sure to check for the existence of the key in __context__ and
generate the key before using it.
generate the key before using it.

41
doc/topics/installation/debian.rst
View file

@ -15,43 +15,16 @@ Installation from official Debian and Raspbian repositories is described
.. _installation-debian-repo:
Installation from the SaltStack Repository
==========================================
Installation from the Official SaltStack Repository
===================================================
2015.5 and later packages for Debian 8 ("Jessie") are available in the
SaltStack repository.
Packages for Debian 8 (Jessie) and Debian 7 (Wheezy) are available in the
Official SaltStack repository.
.. note::
SaltStack repository contains only packages suitable for ``i386`` (32-bit
Intel-compatible CPUs) and ``amd64`` (64-bit) architectures. While Salt
packages are built for all Debian ports (have ``all`` suffix in package
names), some of the dependencies are avaivable only for ``amd64`` systems.
Instructions are at http://repo.saltstack.com/#debian.
.. important::
The repository folder structure changed in the 2015.8.3 release, though the
previous repository structure that was documented in 2015.8.1 can continue to
be used.
To install using the SaltStack repository:
#. Run the following command to import the SaltStack repository key:
.. code-block:: bash
wget -O - https://repo.saltstack.com/apt/debian/8/amd64/latest/SALTSTACK-GPG-KEY.pub | sudo apt-key add -
#. Add the following line to ``/etc/apt/sources.list``:
.. code-block:: bash
deb http://repo.saltstack.com/apt/debian/8/amd64/latest jessie main
#. Run ``sudo apt-get update``.
#. Now go to the :ref:`packages installation <debian-install-pkgs>` section.
Installation from the Community Repository
==========================================
Installation from the Community-Maintained Repository
=====================================================
The SaltStack community maintains a Debian repository at debian.saltstack.com.
Packages for Debian Old Stable, Stable, and Unstable (Wheezy, Jessie, and Sid)

78
doc/topics/installation/rhel.rst
View file

@ -12,76 +12,14 @@ Report any bugs or issues on the `issue tracker`__.
.. __: https://github.com/saltstack/salt/issues
Installation from the SaltStack Repository
==========================================
Installation from the Official SaltStack Repository
===================================================
2015.5 and later packages for RHEL 5, 6, and 7 are available in the
SaltStack repository.
Packages for Redhat, CentOS, and Amazon Linux are available in
the SaltStack Repository.
.. important::
The repository folder structure changed in the 2015.8.3 release, though the
previous repository structure that was documented in 2015.8.1 can continue to
be used.
To install using the SaltStack repository:
#. Run one of the following commands based on your version to import the SaltStack repository key:
Version 7:
.. code-block:: bash
rpm --import https://repo.saltstack.com/yum/redhat/7/x86_64/latest/SALTSTACK-GPG-KEY.pub
Version 6:
.. code-block:: bash
rpm --import https://repo.saltstack.com/yum/redhat/6/x86_64/latest/SALTSTACK-GPG-KEY.pub
Version 5:
.. code-block:: bash
wget https://repo.saltstack.com/yum/redhat/5/x86_64/latest/SALTSTACK-EL5-GPG-KEY.pub
rpm --import SALTSTACK-EL5-GPG-KEY.pub
rm -f SALTSTACK-EL5-GPG-KEY.pub
#. Save the following file to ``/etc/yum.repos.d/saltstack.repo``:
Version 7 and 6:
.. code-block:: cfg
[saltstack-repo]
name=SaltStack repo for RHEL/CentOS $releasever
baseurl=https://repo.saltstack.com/yum/redhat/$releasever/$basearch/latest
enabled=1
gpgcheck=1
gpgkey=https://repo.saltstack.com/yum/redhat/$releasever/$basearch/latest/SALTSTACK-GPG-KEY.pub
Version 5:
.. code-block:: cfg
[saltstack-repo]
name=SaltStack repo for RHEL/CentOS $releasever
baseurl=https://repo.saltstack.com/yum/redhat/$releasever/$basearch/latest
enabled=1
gpgcheck=1
gpgkey=https://repo.saltstack.com/yum/redhat/$releasever/$basearch/latest/SALTSTACK-EL5-GPG-KEY.pub
#. Run ``sudo yum clean expire-cache``.
#. Run ``sudo yum update``.
#. Install the salt-minion, salt-master, or other Salt components:
- ``yum install salt-master``
- ``yum install salt-minion``
- ``yum install salt-ssh``
- ``yum install salt-syndic``
- ``yum install salt-cloud``
- `Red Hat / CentOS <http://repo.saltstack.com/#rhel>`_
- `Amazon Linux <http://repo.saltstack.com/#amzn>`_
.. note::
As of 2015.8.0, EPEL repository is no longer required for installing on
@ -108,8 +46,8 @@ To install using the SaltStack repository:
installed by the Red Hat 7 ``@base`` installation or by the Salt
installation. These dependencies might need to be installed before Salt.
Installation from the Community Repository
==========================================
Installation from the Community-Maintained Repository
=====================================================
Beginning with version 0.9.4, Salt has been available in `EPEL`_. For
RHEL/CentOS 5, `Fedora COPR`_ is a single community repository that provides

13
doc/topics/installation/suse.rst
View file

@ -1,7 +1,20 @@
.. _installation-suse:
====
SUSE
====
Installation from the SaltStack Repository
==========================================
Packages for SUSE 12 SP1, SUSE 12, SUSE 11, openSUSE 13 and openSUSE Leap 42.1
are available in the SaltStack Repository.
Instructions are at http://repo.saltstack.com/#suse.
Installation from the SUSE Repository
=====================================
Since openSUSE 13.2, Salt 2014.1.11 is available in the primary repositories.
With the release of SUSE manager 3 a new repository setup has been created.
The new repo will by systemsmanagement:saltstack, which is the source

54
doc/topics/installation/ubuntu.rst
View file

@ -6,58 +6,16 @@ Ubuntu
.. _installation-ubuntu-repo:
Installation from the SaltStack Repository
==========================================
Installation from the Official SaltStack Repository
===================================================
2015.5 and later packages for Ubuntu 14 (Trusty) and Ubuntu 12 (Precise) are
Packages for Ubuntu 14 (Trusty) and Ubuntu 12 (Precise) are
available in the SaltStack repository.
.. note::
While Salt packages are built for all Ubuntu supported CPU architectures
(``i386`` and ``amd64``), some of the dependencies avaivable from SaltStack
corporate repository are only suitable for ``amd64`` systems.
Instructions are at http://repo.saltstack.com/#ubuntu.
.. important::
The repository folder structure changed in the 2015.8.3 release, though the
previous repository structure that was documented in 2015.8.1 can continue to
be used.
To install using the SaltStack repository:
#. Run the following command to import the SaltStack repository key:
Ubuntu 14:
.. code-block:: bash
wget -O - https://repo.saltstack.com/apt/ubuntu/14.04/amd64/latest/SALTSTACK-GPG-KEY.pub | sudo apt-key add -
Ubuntu 12:
.. code-block:: bash
wget -O - https://repo.saltstack.com/apt/ubuntu/12.04/amd64/latest/SALTSTACK-GPG-KEY.pub | sudo apt-key add -
#. Add the following line to ``/etc/apt/sources.list``:
Ubuntu 14:
.. code-block:: bash
deb http://repo.saltstack.com/apt/ubuntu/14.04/amd64/latest trusty main
Ubuntu 12:
.. code-block:: bash
deb http://repo.saltstack.com/apt/ubuntu/12.04/amd64/latest precise main
#. Run ``sudo apt-get update``.
#. Now go to the :ref:`packages installation <ubuntu-install-pkgs>` section.
Installation from the Community Repository
==========================================
Installation from the Community-Maintained Repository
=====================================================
Packages for Ubuntu are also published in the saltstack PPA. If you have
the ``add-apt-repository`` utility, you can add the repository and import the

6
doc/topics/master_tops/index.rst
View file

@ -3,8 +3,8 @@ Master Tops System
==================
In 0.10.4 the `external_nodes` system was upgraded to allow for modular
subsystems to be used to generate the top file data for a highstate run on
the master.
subsystems to be used to generate the top file data for a :ref:`highstate
<running-highstate>` run on the master.
The old `external_nodes` option has been removed.
The master tops system contains a number of subsystems that
@ -74,4 +74,4 @@ a degenerate example:
minion
----------
base:
- test
- test

9
doc/topics/pillar/index.rst
View file

@ -352,14 +352,9 @@ Pillar data can be set at the command line like the following example:
.. code-block:: bash
salt '*' state.highstate pillar='{"cheese": "spam"}'
salt '*' state.apply pillar='{"cheese": "spam"}'
This will create a dict with a key of 'cheese' and a value of 'spam'. A list
can be created like this:
.. code-block:: bash
salt '*' state.highstate pillar='["cheese", "milk", "bread"]'
This will add a Pillar key of ``cheese`` with its value set to ``spam``.
.. note::

55
doc/topics/reactor/index.rst
View file

@ -74,7 +74,7 @@ Here is a simple reactor sls:
{% if data['id'] == 'mysql1' %}
highstate_run:
local.state.highstate:
local.state.apply:
- tgt: mysql1
{% endif %}
@ -84,8 +84,8 @@ the minion is ``mysql1``) then the following reaction is defined. The same
data structure and compiler used for the state system is used for the reactor
system. The only difference is that the data is matched up to the salt command
API and the runner system. In this example, a command is published to the
``mysql1`` minion with a function of ``state.highstate``. Similarly, a runner
can be called:
``mysql1`` minion with a function of :py:func:`state.apply
<salt.modules.state.apply_>`. Similarly, a runner can be called:
.. code-block:: yaml
@ -394,8 +394,8 @@ Passing event data to Minions or Orchestrate as Pillar
------------------------------------------------------
An interesting trick to pass data from the Reactor script to
``state.highstate`` or ``state.sls`` is to pass it as inline Pillar data since
both functions take a keyword argument named ``pillar``.
:py:func:`state.apply <salt.modules.state.apply_>` is to pass it as inline
Pillar data since both functions take a keyword argument named ``pillar``.
The following example uses Salt's Reactor to listen for the event that is fired
when the key for a new minion is accepted on the master using ``salt-key``.
@ -408,9 +408,9 @@ when the key for a new minion is accepted on the master using ``salt-key``.
- 'salt/key':
- /srv/salt/haproxy/react_new_minion.sls
The Reactor then fires a ``state.sls`` command targeted to the HAProxy servers
and passes the ID of the new minion from the event to the state file via inline
Pillar.
The Reactor then fires a ::py:func:`state.apply <salt.modules.state.apply_>`
command targeted to the HAProxy servers and passes the ID of the new minion
from the event to the state file via inline Pillar.
:file:`/srv/salt/haproxy/react_new_minion.sls`:
@ -418,7 +418,7 @@ Pillar.
{% if data['act'] == 'accept' and data['id'].startswith('web') %}
add_new_minion_to_pool:
local.state.sls:
local.state.apply:
- tgt: 'haproxy*'
- arg:
- haproxy.refresh_pool
@ -431,7 +431,7 @@ The above command is equivalent to the following command at the CLI:
.. code-block:: bash
salt 'haproxy*' state.sls haproxy.refresh_pool 'pillar={new_minion: minionid}'
salt 'haproxy*' state.apply haproxy.refresh_pool 'pillar={new_minion: minionid}'
This works with Orchestrate files as well:
@ -479,9 +479,9 @@ In this example, we're going to assume that we have a group of servers that
will come online at random and need to have keys automatically accepted. We'll
also add that we don't want all servers being automatically accepted. For this
example, we'll assume that all hosts that have an id that starts with 'ink'
will be automatically accepted and have state.highstate executed. On top of
this, we're going to add that a host coming up that was replaced (meaning a new
key) will also be accepted.
will be automatically accepted and have :py:func:`state.apply
<salt.modules.state.apply_>` executed. On top of this, we're going to add that
a host coming up that was replaced (meaning a new key) will also be accepted.
Our master configuration will be rather simple. All minions that attempte to
authenticate will match the :strong:`tag` of :strong:`salt/auth`. When it comes
@ -536,17 +536,17 @@ Ink servers in the master configuration.
.. code-block:: yaml
{# When an Ink server connects, run state.highstate. #}
{# When an Ink server connects, run state.apply. #}
highstate_run:
local.state.highstate:
local.state.apply:
- tgt: {{ data['id'] }}
- ret: smtp
The above will also return the highstate result data using the `smtp_return`
returner (use virtualname like when using from the command line with `--return`).
The returner needs to be configured on the minion for this to work.
See :mod:`salt.returners.smtp_return <salt.returners.smtp_return>` documentation
for that.
The above will also return the :ref:`highstate <running-highstate>` result data
using the `smtp_return` returner (use virtualname like when using from the
command line with `--return`). The returner needs to be configured on the
minion for this to work. See :mod:`salt.returners.smtp_return
<salt.returners.smtp_return>` documentation for that.
.. _minion-start-reactor:
@ -554,11 +554,12 @@ Syncing Custom Types on Minion Start
====================================
Salt will sync all custom types (by running a :mod:`saltutil.sync_all
<salt.modules.saltutil.sync_all>`) on every highstate. However, there is a
chicken-and-egg issue where, on the initial highstate, a minion will not yet
have these custom types synced when the top file is first compiled. This can be
worked around with a simple reactor which watches for ``minion_start`` events,
which each minion fires when it first starts up and connects to the master.
<salt.modules.saltutil.sync_all>`) on every :ref:`highstate
<running-highstate>`. However, there is a chicken-and-egg issue where, on the
initial :ref:`highstate <running-highstate>`, a minion will not yet have these
custom types synced when the top file is first compiled. This can be worked
around with a simple reactor which watches for ``minion_start`` events, which
each minion fires when it first starts up and connects to the master.
On the master, create **/srv/reactor/sync_grains.sls** with the following
contents:
@ -578,8 +579,8 @@ And in the master config file, add the following reactor configuration:
- /srv/reactor/sync_grains.sls
This will cause the master to instruct each minion to sync its custom grains
when it starts, making these grains available when the initial highstate is
executed.
when it starts, making these grains available when the initial :ref:`highstate
<running-highstate>` is executed.
Other types can be synced by replacing ``local.saltutil.sync_grains`` with
``local.saltutil.sync_modules``, ``local.saltutil.sync_all``, or whatever else

37
doc/topics/releases/2015.5.10.rst
View file

@ -1,5 +1,34 @@
==========================================
Salt 2015.5.10 Release Notes (In Progress)
==========================================
============================
Salt 2015.5.10 Release Notes
============================
Security Fix
============
CVE-2016-3176: Insecure configuration of PAM external authentication service
This issue affects all Salt versions prior to 2015.8.8/2015.5.10 when PAM
:ref:`external authentication <acl-eauth>` is enabled. This issue involves
passing an alternative PAM authentication service with a command that is sent
to :ref:`LocalClient <local-client>`, enabling the attacker to bypass the
configured authentication service. Thank you to Dylan Frese <dmfrese@gmail.com>
for bringing this issue to our attention.
This update defines the PAM eAuth ``service`` that users authenticate against
in the Salt Master configuration.
(No additional fixes are contained in this release).
Read Before Upgrading Debian 8 (Jessie) from Salt Versions Earlier than 2015.5.9
================================================================================
Salt ``systemd`` service files are missing the following statement in these versions:
.. code-block:: ini
[Service]
KillMode=process
This statement must be added to successfully upgrade on these earlier versions
of Salt.
In progress, not yet released.

6
doc/topics/releases/2015.5.11.rst Normal file
View file

@ -0,0 +1,6 @@
==========================================
Salt 2015.5.11 Release Notes (In Progress)
==========================================
In progress, not yet released.

62
doc/topics/releases/2015.8.8.rst
View file

@ -2,6 +2,66 @@
Salt 2015.8.8 Release Notes
===========================
Security Fix
============
CVE-2016-3176: Insecure configuration of PAM external authentication service
This issue affects all Salt versions prior to 2015.8.8/2015.5.10 when PAM
:ref:`external authentication <acl-eauth>` is enabled. This issue involves
passing an alternative PAM authentication service with a command that is sent
to :ref:`LocalClient <local-client>`, enabling the attacker to bypass the
configured authentication service. Thank you to Dylan Frese <dmfrese@gmail.com>
for bringing this issue to our attention.
This update defines the PAM eAuth ``service`` that users authenticate against
in the Salt Master configuration.
Known Issues
============
Failed to import module win_dacl Error
--------------------------------------
:issue:`32004`: This error occurs on Solarish platforms, a fix is being
investigated.
Key master with value [...] has an invalid type of list Error
-------------------------------------------------------------
:issue:`32044`: This error occurs in multimaster environments, a fix is being
investigated.
Read Before Upgrading Debian 7 (Wheezy) from 2015.8.7 to 2015.8.8
-----------------------------------------------------------------
Before you upgrade from 2015.8.7 on Debian 7, you must run the following
commands to remove previous packages:
.. code-block:: bash
sudo apt-get remove python-pycrypto
sudo apt-get remove python-apache-libcloud
Note that ``python-pycrypto`` will likely remove ``python-apache-libcloud``, so
the second command might not be necessary. These have been replaced by
``python-crypto`` and ``python-libcloud`` with ~bpo70+1 moniker.
Read Before Upgrading Debian 8 (Jessie) from Salt Versions Earlier than 2015.8.4
--------------------------------------------------------------------------------
Salt ``systemd`` service files are missing the following statement in these versions:
.. code-block:: ini
[Service]
KillMode=process
This statement must be added to successfully upgrade on these earlier versions
of Salt.
Changes for v2015.8.7..v2015.8.8
--------------------------------
@ -411,7 +471,7 @@ Changes:
- **PR** `#30750`_: (*jfindlay*) extract whole war version
- **PR** `#30884`_: (*rallytime*) Move checks for private_key file existence and permissions to create function
- **PR** `#30884`_: (*rallytime*) Move checks for private_key file existence and permissions to create function
- **PR** `#30888`_: (*ticosax*) Backport `#30797`_ to 2015.8

6
doc/topics/releases/2015.8.9.rst Normal file
View file

@ -0,0 +1,6 @@
=========================================
Salt 2015.8.9 Release Notes (In Progress)
=========================================
In progress, not yet released.

1
doc/topics/targeting/grains.rst
View file

@ -33,3 +33,4 @@ has a value that contains the word ``production``:
.. important::
See :ref:`Is Targeting using Grain Data Secure? <faq-grain-security>` for
important security information.

16
doc/topics/troubleshooting/index.rst
View file

@ -85,17 +85,17 @@ The ``salt-call`` command was originally developed for aiding in the development
of new Salt modules. Since then, many applications have been developed for
running any Salt module locally on a minion. These range from the original
intent of salt-call, development assistance, to gathering more verbose output
from calls like :mod:`state.highstate <salt.modules.state.highstate>`.
from calls like :mod:`state.apply <salt.modules.state.apply_>`.
When creating your state tree, it is generally recommended to invoke
:mod:`state.highstate <salt.modules.state.highstate>` with ``salt-call``. This
displays far more information about the highstate execution than calling it
remotely. For even more verbosity, increase the loglevel with the same argument
as ``salt-minion``:
When initially creating your state tree, it is generally recommended to invoke
:mod:`state.apply <salt.modules.state.apply_>` directly from the minion with
``salt-call``, rather than remotely from the master. This displays far more
information about the execution than calling it remotely. For even more
verbosity, increase the loglevel using the ``-l`` argument:
.. code-block:: bash
salt-call -l debug state.highstate
salt-call -l debug state.apply
The main difference between using ``salt`` and using ``salt-call`` is that
``salt-call`` is run from the minion, and it only runs the selected function on
@ -262,4 +262,4 @@ Debugging the Master and Minion
A list of common :doc:`master</topics/troubleshooting/master>` and
:doc:`minion</topics/troubleshooting/minion>` troubleshooting steps provide a
starting point for resolving issues you may encounter.
starting point for resolving issues you may encounter.

5
doc/topics/troubleshooting/master.rst
View file

@ -181,8 +181,9 @@ Commands Time Out or Do Not Return Output
=========================================
Depending on your OS (this is most common on Ubuntu due to apt-get) you may
sometimes encounter times where your highstate, or other long running commands
do not return output.
sometimes encounter times where a :py:func:`state.apply
<salt.modules.state.apply_>`, or other long running commands do not return
output.
By default the timeout is set to 5 seconds. The timeout value can easily be
increased by modifying the ``timeout`` line within your ``/etc/salt/master``

22
doc/topics/troubleshooting/minion.rst
View file

@ -71,21 +71,21 @@ check that no additional access control system such as `SELinux`_ or
Using salt-call
===============
The ``salt-call`` command was originally developed for aiding in the development
of new Salt modules. Since then, many applications have been developed for
running any Salt module locally on a minion. These range from the original
intent of salt-call, development assistance, to gathering more verbose output
from calls like :mod:`state.highstate <salt.modules.state.highstate>`.
The ``salt-call`` command was originally developed for aiding in the
development of new Salt modules. Since then, many applications have been
developed for running any Salt module locally on a minion. These range from the
original intent of salt-call (development assistance), to gathering more
verbose output from calls like :mod:`state.apply <salt.modules.state.apply_>`.
When initially creating your state tree, it is generally recommended to invoke
:mod:`state.highstate <salt.modules.state.highstate>` from the minion with
``salt-call``. This displays far more information about the highstate execution
than calling it remotely. For even more verbosity, increase the loglevel with
the same argument as ``salt-minion``:
highstates by running :mod:`state.apply <salt.modules.state.apply_>` directly
from the minion with ``salt-call``, rather than remotely from the master. This
displays far more information about the execution than calling it remotely. For
even more verbosity, increase the loglevel using the ``-l`` argument:
.. code-block:: bash
# salt-call -l debug state.highstate
# salt-call -l debug state.apply
The main difference between using ``salt`` and using ``salt-call`` is that
``salt-call`` is run from the minion, and it only runs the selected function on
@ -148,4 +148,4 @@ salt-minion service.
Modifying the minion timeout value is not required when running commands
from a Salt Master. It is only required when running commands locally on
the minion.
the minion.

30
doc/topics/tutorials/cron.rst
View file

@ -1,32 +1,38 @@
===============================================
Using cron with Salt
===============================================
====================
The Salt Minion can initiate its own highstate using the ``salt-call`` command.
The Salt Minion can initiate its own :ref:`highstate <running-highstate>` using
the ``salt-call`` command.
.. code-block:: bash
$ salt-call state.highstate
$ salt-call state.apply
This will cause the minion to check in with the master and ensure it is in the
correct 'state'.
correct "state".
Use cron to initiate a highstate
================================
If you would like the Salt Minion to regularly check in with the master you can
use the venerable cron to run the ``salt-call`` command.
use cron to run the ``salt-call`` command:
.. code-block:: bash
# PATH=/bin:/sbin:/usr/bin:/usr/sbin
0 0 * * * salt-call state.apply
00 00 * * * salt-call state.highstate
The above cron entry will run a highstate every day at midnight.
The above cron entry will run a :ref:`highstate <running-highstate>` every day
at midnight.
.. note::
Be aware that you may need to ensure the PATH for cron includes any
scripts or commands that need to be executed.
When executing Salt using cron, keep in mind that the default PATH for cron
may not include the path for any scripts or commands used by Salt, and it
may be necessary to set the PATH accordingly in the crontab:
.. code-block:: cron
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin
0 0 * * * salt-call state.apply

10
doc/topics/tutorials/multimaster_pki.rst
View file

@ -149,10 +149,11 @@ In a case like this, it should be checked, that the verification pubkey
Once the verification is successful, the minion can be started in daemon mode
again.
For the paranoid among us, its also possible to verify the public whenever it
is received from the master. That is, for every single auth-attempt which can be
quite frequent. For example just the start of the minion will force the signature
to be checked 6 times for various things like auth, mine, highstate, etc.
For the paranoid among us, its also possible to verify the publication whenever
it is received from the master. That is, for every single auth-attempt which
can be quite frequent. For example just the start of the minion will force the
signature to be checked 6 times for various things like auth, mine,
:ref:`highstate <running-highstate>`, etc.
If that is desired, enable the setting
@ -162,7 +163,6 @@ If that is desired, enable the setting
always_verify_signature: True
Multiple Masters For A Minion
=============================

15
doc/topics/tutorials/pillar.rst
View file

@ -297,18 +297,13 @@ Ensuring that the right vimrc is sent out to the correct minions.
Setting Pillar Data on the Command Line
=======================================
Pillar data can be set on the command line like so:
Pillar data can be set on the command line when running :py:func:`state.apply
<salt.modules.state.apply_` like so:
.. code-block:: bash
salt '*' state.highstate pillar='{"foo": "bar"}'
The ``state.sls`` command can also be used to set pillar values via the command
line:
.. code-block:: bash
salt '*' state.sls my_sls_file pillar='{"hello": "world"}'
salt '*' state.apply pillar='{"foo": "bar"}'
salt '*' state.apply my_sls_file pillar='{"hello": "world"}'
Nested pillar values can also be set via the command line:
@ -327,7 +322,7 @@ specified list, notice the nested pillar dict:
.. code-block:: bash
salt '*' state.sls edit.vim pillar='{"pkgs": {"vim": "telnet"}}'
salt '*' state.apply edit.vim pillar='{"pkgs": {"vim": "telnet"}}'
.. note::

6
doc/topics/tutorials/preseed_key.rst
View file

@ -63,6 +63,6 @@ You will want to place the minion keys before starting the salt-minion daemon:
/etc/salt/pki/minion/minion.pem
/etc/salt/pki/minion/minion.pub
Once in place, you should be able to start salt-minion and run
``salt-call state.highstate`` or any other salt commands that require master
authentication.
Once in place, you should be able to start salt-minion and run ``salt-call
state.apply`` or any other salt commands that require master authentication.

17
doc/topics/tutorials/quickstart.rst
View file

@ -104,21 +104,20 @@ ensures that the server has the Apache webserver installed.
instance on Debian/Ubuntu it is apache2, on Fedora/RHEL it is httpd
and on Arch it is apache
The only thing left is to provision our minion using salt-call and the
highstate command.
The only thing left is to provision our minion using ``salt-call``.
Salt-call
---------
The salt-call command is used to run module functions locally on a minion
instead of executing them from the master. Normally the salt-call command
checks into the master to retrieve file server and pillar data, but when
running standalone salt-call needs to be instructed to not check the master for
this data:
The salt-call command is used to run remote execution functions locally on a
minion instead of executing them from the master. Normally the salt-call
command checks into the master to retrieve file server and pillar data, but
when running standalone salt-call needs to be instructed to not check the
master for this data:
.. code-block:: bash
salt-call --local state.highstate
salt-call --local state.apply
The ``--local`` flag tells the salt-minion to look for the state tree in the
local file system and not to contact a Salt Master for instructions.
@ -127,7 +126,7 @@ To provide verbose output, use ``-l debug``:
.. code-block:: bash
salt-call --local state.highstate -l debug
salt-call --local state.apply -l debug
The minion first examines the ``top.sls`` file and determines that it is a part
of the group matched by ``*`` glob and that the ``webserver`` SLS should be applied.

4
doc/topics/tutorials/standalone_minion.rst
View file

@ -72,14 +72,14 @@ The declared state can now be executed with:
.. code-block:: bash
salt-call state.highstate
salt-call state.apply
Or the salt-call command can be executed with the ``--local`` flag, this makes
it unnecessary to change the configuration file:
.. code-block:: bash
salt-call state.highstate --local
salt-call state.apply --local
External Pillars
================

15
doc/topics/tutorials/starting_states.rst
View file

@ -538,12 +538,17 @@ Running and debugging salt states.
Once the rules in an SLS are ready, they should be tested to ensure they
work properly. To invoke these rules, simply execute
``salt '*' state.highstate`` on the command line. If you get back only
``salt '*' state.apply`` on the command line. If you get back only
hostnames with a ``:`` after, but no return, chances are there is a problem with
one or more of the sls files. On the minion, use the ``salt-call`` command:
``salt-call state.highstate -l debug`` to examine the output for errors.
This should help troubleshoot the issue. The minions can also be started in
the foreground in debug mode: ``salt-minion -l debug``.
one or more of the sls files. On the minion, use the ``salt-call`` command to
examine the output for errors:
.. code-block:: bash
salt-call state.apply -l debug
This should help troubleshoot the issue. The minion can also be started in the
foreground in debug mode by running ``salt-minion -l debug``.
Next Reading
============

44
doc/topics/tutorials/states_pt1.rst
View file

@ -68,7 +68,7 @@ collection of minion matches is defined; for now simply specify all hosts
.. code-block:: yaml
base:
'os:Fedora':
'G@os:Fedora':
- match: grain
- webserver
@ -125,13 +125,31 @@ Next, let's run the state we created. Open a terminal on the master and run:
.. code-block:: bash
% salt '*' state.highstate
salt '*' state.apply
Our master is instructing all targeted minions to run :func:`state.highstate
<salt.modules.state.highstate>`. When a minion executes a highstate call it
will download the :ref:`top file <states-top>` and attempt to match the
expressions. When it does match an expression the modules listed for it will be
downloaded, compiled, and executed.
Our master is instructing all targeted minions to run :func:`state.apply
<salt.modules.state.apply>`. When this function is executied without any SLS
targets, a minion will download the :ref:`top file <states-top>` and attempt to
match the expressions within it. When the minion does match an expression the
modules listed for it will be downloaded, compiled, and executed.
.. note::
This action is referred to as a "highstate", and can be run using the
:py:func:`state.highstate <salt.modules.state.highstate>` function.
However, to make the usage easier to understand ("highstate" is not
necessarily an intuitive name), a :py:func:`state.apply
<salt.modules.state.apply_>` function was added in version 2015.5.0, which
when invoked without any SLS names will trigger a highstate.
:py:func:`state.highstate <salt.modules.state.highstate>` still exists and
can be used, but the documentation (as can be seen above) has been updated
to reference :py:func:`state.apply <salt.modules.state.apply_>`, so keep
the following in mind as you read the documentation:
- :py:func:`state.apply <salt.modules.state.apply_>` invoked without any
SLS names will run :py:func:`state.highstate
<salt.modules.state.highstate>`
- :py:func:`state.apply <salt.modules.state.apply_>` invoked with SLS names
will run :py:func:`state.sls <salt.modules.state.sls>`
Once completed, the minion will report back with a summary of all actions taken
and all changes made.
@ -141,9 +159,9 @@ and all changes made.
If you have created :ref:`custom grain modules <writing-grains>`, they will
not be available in the top file until after the first :ref:`highstate
<running-highstate>`. To make custom grains available on a minion's first
highstate, it is recommended to use :ref:`this example
<minion-start-reactor>` to ensure that the custom grains are synced when
the minion starts.
:ref:`highstate <running-highstate>`, it is recommended to use :ref:`this
example <minion-start-reactor>` to ensure that the custom grains are synced
when the minion starts.
.. _sls-file-namespace:
.. admonition:: SLS File Namespace
@ -190,7 +208,7 @@ and all changes made.
.. code-block:: bash
salt-minion &
salt-minion
Increase the default timeout value when running :command:`salt`. For
example, to change the default timeout to 60 seconds:
@ -203,8 +221,8 @@ and all changes made.
.. code-block:: bash
salt-minion -l debug & # On the minion
salt '*' state.highstate -t 60 # On the master
salt-minion -l debug # On the minion
salt '*' state.apply -t 60 # On the master
Next steps
==========

12
doc/topics/tutorials/states_pt2.rst
View file

@ -28,8 +28,8 @@ You can specify multiple :ref:`state-declaration` under an
- require:
- pkg: apache
Try stopping Apache before running ``state.highstate`` once again and observe
the output.
Try stopping Apache before running :py:func:`state.apply
<salt.modules.state.apply_>` once again and observe the output.
.. note::
@ -101,13 +101,13 @@ directory:
</body>
</html>
Last, call :func:`state.highstate <salt.modules.state.highstate>` again and the
minion will fetch and execute the highstate as well as our HTML file from the
master using Salt's File Server:
Last, call :func:`state.apply <salt.modules.state.apply_>` again and the minion
will fetch and execute the :ref:`highstate <running-highstate>` as well as our
HTML file from the master using Salt's File Server:
.. code-block:: bash
salt '*' state.highstate
salt '*' state.apply
Verify that Apache is now serving your custom HTML.

15
doc/topics/tutorials/states_pt4.rst
View file

@ -153,20 +153,21 @@ Given the above SLS, the source for the website should initially be placed in
``/srv/salt/dev/webserver/src/foobarcom``.
First, let's deploy to dev. Given the configuration in the top file, this can
be done using :mod:`state.highstate <salt.modules.state.highstate>`:
be done using :py:func:`state.apply <salt.modules.state.apply_>`:
.. code-block:: bash
salt --pillar 'webserver_role:dev' state.highstate
salt --pillar 'webserver_role:dev' state.apply
However, in the event that it is not desirable to apply all states configured
in the top file (which could be likely in more complex setups), it is possible
to apply just the states for the ``foobarcom`` website, using :mod:`state.sls
<salt.modules.state.sls>`:
to apply just the states for the ``foobarcom`` website, by invoking
:py:func:`state.apply <salt.modules.state.apply_>` with the desired SLS target
as an argument:
.. code-block:: bash
salt --pillar 'webserver_role:dev' state.sls webserver.foobarcom
salt --pillar 'webserver_role:dev' state.apply webserver.foobarcom
Once the site has been tested in dev, then the files can be moved from
``/srv/salt/dev/webserver/src/foobarcom`` to
@ -174,7 +175,7 @@ Once the site has been tested in dev, then the files can be moved from
.. code-block:: bash
salt --pillar 'webserver_role:qa' state.sls webserver.foobarcom
salt --pillar 'webserver_role:qa' state.apply webserver.foobarcom
Finally, once the site has been tested in qa, then the files can be moved from
``/srv/salt/qa/webserver/src/foobarcom`` to
@ -182,7 +183,7 @@ Finally, once the site has been tested in qa, then the files can be moved from
.. code-block:: bash
salt --pillar 'webserver_role:prod' state.sls webserver.foobarcom
salt --pillar 'webserver_role:prod' state.apply webserver.foobarcom
Thanks to Salt's fileserver inheritance, even though the files have been moved
to within ``/srv/salt/prod``, they are still available from the same

1
doc/topics/tutorials/states_pt5.rst
View file

@ -5,3 +5,4 @@ States Tutorial, Part 5 - Orchestration with Salt
=================================================
This was moved to :ref:`Orchestrate Runner <orchestrate-runner>`.

13
doc/topics/tutorials/walkthrough.rst
View file

@ -510,7 +510,7 @@ Now install vim on the minions by calling the SLS directly:
.. code-block:: bash
salt '*' state.sls vim
salt '*' state.apply vim
This command will invoke the state system and run the ``vim`` SLS.
@ -586,14 +586,13 @@ This formula can be referenced via the following command:
.. code-block:: bash
salt '*' state.sls nginx
salt '*' state.apply nginx
.. note::
Reminder!
Just as one could call the ``test.ping`` or ``disk.usage`` execution modules,
``state.sls`` is simply another execution module. It simply takes the name of an
SLS file as an argument.
:py:func:`state.apply <salt.modules.state.apply_>` is just another remote
execution function, just like :py:func:`test.ping <salt.modules.test.ping>`
or :py:func:`disk.usage <salt.modules.disk.usage>`. It simply takes the
name of an SLS file as an argument.
Now that subdirectories can be used, the ``vim.sls`` formula can be cleaned up.
To make things more flexible, move the ``vim.sls`` and vimrc into a new subdirectory

25
doc/topics/tutorials/walkthrough_macosx.rst
View file

@ -429,10 +429,10 @@ error saying the site cannot be reached.
Initialize the top.sls file
---------------------------
System configuration is done in the /srv/salt/top.sls file (and
subfiles/folders), and then applied by running the ``state.highstate``
command to have the Salt master give orders so minions will update their
instructions and run the associated commands.
System configuration is done in ``/srv/salt/top.sls`` (and subfiles/folders),
and then applied by running the :py:func:`state.apply
<salt.modules.state.apply_>` function to have the Salt master order its minions
to update their instructions and run the associated commands.
First Create an empty file on your Salt master (Mac OS X machine):
@ -445,10 +445,10 @@ an error is reported:
.. code-block:: bash
sudo salt 'minion1' state.highstate
sudo salt 'minion1' state.apply
Should return an error stating:
"No Top file or external nodes data matches found".
This should return an error stating: **No Top file or external nodes data
matches found**.
Create The Nginx Configuration
------------------------------
@ -457,8 +457,8 @@ Now is finally the time to enter the real meat of our server's configuration.
For this tutorial our minion will be treated as a web server that needs to
have Nginx installed.
Insert the following lines into the ``/srv/salt/top.sls`` file (which should
current be empty).
Insert the following lines into ``/srv/salt/top.sls`` (which should current be
empty).
.. code-block:: yaml
@ -466,7 +466,7 @@ current be empty).
'minion1':
- bin.nginx
Now create a ``/srv/salt/bin/nginx.sls`` file containing the following:
Now create ``/srv/salt/bin/nginx.sls`` containing the following:
.. code-block:: yaml
@ -480,11 +480,12 @@ Now create a ``/srv/salt/bin/nginx.sls`` file containing the following:
Check Minion State
------------------
Finally run the state.highstate command again:
Finally, run the :py:func:`state.apply <salt.modules.state.apply_>` function
again:
.. code-block:: bash
sudo salt 'minion1' state.highstate
sudo salt 'minion1' state.apply
You should see a log showing that the Nginx package has been installed
and the service configured. To prove it, open your browser and navigate to

4
pkg/suse/use-forking-daemon.patch
View file

@ -7,7 +7,7 @@ Index: salt-2015.8.0/pkg/salt-master.service
[Service]
LimitNOFILE=16384
-Type=notify
-NotifyAccess=all
+Type=simple
ExecStart=/usr/bin/salt-master
[Install]
KillMode=process

6
salt/auth/ldap.py
View file

@ -95,8 +95,10 @@ class _LDAPConnection(object):
self.binddn = binddn
self.bindpw = bindpw
if not HAS_LDAP:
raise CommandExecutionError('Failed to connect to LDAP, module '
'not loaded')
raise CommandExecutionError(
'LDAP connection could not be made, the python-ldap module is '
'not installed. Install python-ldap to use LDAP external auth.'
)
if self.uri == '':
self.uri = '{0}://{1}:{2}'.format(schema, self.server, self.port)

64
salt/config/__init__.py
View file

@ -64,7 +64,7 @@ FLO_DIR = os.path.join(
VALID_OPTS = {
# The address of the salt master. May be specified as IP address or hostname
'master': str,
'master': (str, list),
# The TCP/UDP port of the master to connect to in order to listen to publications
'master_port': int,
@ -563,7 +563,7 @@ VALID_OPTS = {
'file_recv': bool,
'file_recv_max_size': int,
'file_ignore_regex': list,
'file_ignore_glob': bool,
'file_ignore_glob': list,
'fileserver_backend': list,
'fileserver_followsymlinks': bool,
'fileserver_ignoresymlinks': bool,
@ -869,7 +869,7 @@ DEFAULT_MINION_OPTS = {
'file_recv': False,
'file_recv_max_size': 100,
'file_ignore_regex': [],
'file_ignore_glob': None,
'file_ignore_glob': [],
'fileserver_backend': ['roots'],
'fileserver_followsymlinks': True,
'fileserver_ignoresymlinks': False,
@ -1395,26 +1395,30 @@ def _validate_opts(opts):
Check that all of the types of values passed into the config are
of the right types
'''
def format_multi_opt(valid_type):
try:
num_types = len(valid_type)
except TypeError:
# Bare type name won't have a length, return the name of the type
# passed.
return valid_type.__name__
else:
if num_types == 1:
return valid_type.__name__
elif num_types > 1:
ret = ', '.join(x.__name__ for x in valid_type[:-1])
ret += ' or ' + valid_type[-1].__name__
errors = []
err = ('Key {0} with value {1} has an invalid type of {2}, a {3} is '
err = ('Key \'{0}\' with value {1} has an invalid type of {2}, a {3} is '
'required for this value')
for key, val in six.iteritems(opts):
if key in VALID_OPTS:
if isinstance(VALID_OPTS[key](), list):
if isinstance(val, VALID_OPTS[key]):
continue
else:
errors.append(
err.format(key, val, type(val).__name__, 'list')
)
if isinstance(VALID_OPTS[key](), dict):
if isinstance(val, VALID_OPTS[key]):
continue
else:
errors.append(
err.format(key, val, type(val).__name__, 'dict')
)
else:
if isinstance(val, VALID_OPTS[key]):
continue
if hasattr(VALID_OPTS[key], '__call__'):
try:
VALID_OPTS[key](val)
if isinstance(val, (list, dict)):
@ -1431,14 +1435,21 @@ def _validate_opts(opts):
VALID_OPTS[key].__name__
)
)
except ValueError:
except (TypeError, ValueError):
errors.append(
err.format(key, val, type(val).__name__, VALID_OPTS[key])
)
except TypeError:
errors.append(
err.format(key, val, type(val).__name__, VALID_OPTS[key])
err.format(key,
val,
type(val).__name__,
VALID_OPTS[key].__name__)
)
continue
errors.append(
err.format(key,
val,
type(val).__name__,
format_multi_opt(VALID_OPTS[key].__name__))
)
# RAET on Windows uses 'win32file.CreateMailslot()' for IPC. Due to this,
# sock_dirs must start with '\\.\mailslot\' and not contain any colons.
@ -1451,7 +1462,7 @@ def _validate_opts(opts):
'\\\\.\\mailslot\\' + opts['sock_dir'].replace(':', ''))
for error in errors:
log.warning(error)
log.debug(error)
if errors:
return False
return True
@ -1897,7 +1908,6 @@ def cloud_config(path, env_var='SALT_CLOUD_CONFIG', defaults=None,
os.path.abspath(
os.path.join(
os.path.dirname(__file__),
'..',
'cloud',
'deploy'
)

6
salt/crypt.py
View file

@ -316,7 +316,7 @@ class AsyncAuth(object):
def __new__(cls, opts, io_loop=None):
'''
Only create one instance of SAuth per __key()
Only create one instance of AsyncAuth per __key()
'''
# do we have any mapping for this io_loop
io_loop = io_loop or tornado.ioloop.IOLoop.current()
@ -326,7 +326,7 @@ class AsyncAuth(object):
key = cls.__key(opts)
if key not in loop_instance_map:
log.debug('Initializing new SAuth for {0}'.format(key))
log.debug('Initializing new AsyncAuth for {0}'.format(key))
# we need to make a local variable for this, as we are going to store
# it in a WeakValueDictionary-- which will remove the item if no one
# references it-- this forces a reference while we return to the caller
@ -334,7 +334,7 @@ class AsyncAuth(object):
new_auth.__singleton_init__(opts, io_loop=io_loop)
loop_instance_map[key] = new_auth
else:
log.debug('Re-using SAuth for {0}'.format(key))
log.debug('Re-using AsyncAuth for {0}'.format(key))
return loop_instance_map[key]
@classmethod

1
salt/minion.py
View file

@ -476,6 +476,7 @@ class MinionBase(object):
log.error(msg)
sys.exit(salt.defaults.exitcodes.EX_GENERIC)
# FIXME: if SMinion don't define io_loop, it can't switch master see #29088
# Specify kwargs for the channel factory so that SMinion doesn't need to define an io_loop
# (The channel factories will set a default if the kwarg isn't passed)
factory_kwargs = {'timeout': timeout, 'safe': safe}

2
salt/modules/dockerng.py
View file

@ -400,7 +400,7 @@ VALID_CREATE_OPTS = {
'memory_swap': {
'api_name': 'memswap_limit',
'path': 'HostConfig:MemorySwap',
'default': 0,
'get_default_from_container': True,
},
'mac_address': {
'validator': 'string',

2
salt/modules/pacman.py
View file

@ -29,7 +29,7 @@ def __virtual__():
'''
Set the virtual pkg module if the os is Arch
'''
if __grains__['os'] in ('Arch', 'Arch ARM', 'Antergos'):
if __grains__['os'] in ('Arch', 'Arch ARM', 'Antergos', 'ManjaroLinux'):
return __virtualname__
return (False, 'The pacman module could not be loaded: unsupported OS family.')

228
salt/modules/state.py
View file

@ -47,7 +47,6 @@ __outputter__ = {
'highstate': 'highstate',
'template': 'highstate',
'template_str': 'highstate',
'apply': 'highstate',
'apply_': 'highstate',
'request': 'highstate',
'check_request': 'highstate',
@ -110,9 +109,9 @@ def _wait(jid):
def running(concurrent=False):
'''
Return a list of strings that contain state return data if a state function is
already running. This function is used to prevent multiple state calls from being
run at the same time.
Return a list of strings that contain state return data if a state function
is already running. This function is used to prevent multiple state calls
from being run at the same time.
CLI Example:
@ -179,7 +178,9 @@ def _get_opts(localconfig=None):
def low(data, queue=False, **kwargs):
'''
Execute a single low data call
This function is mostly intended for testing the state system
This function is mostly intended for testing the state system and is not
likely to be needed in everyday usage.
CLI Example:
@ -209,7 +210,9 @@ def low(data, queue=False, **kwargs):
def high(data, test=False, queue=False, **kwargs):
'''
Execute the compound calls stored in a single set of high data
This function is mostly intended for testing the state system
This function is mostly intended for testing the state system andis not
likely to be needed in everyday usage.
CLI Example:
@ -316,17 +319,127 @@ def apply_(mods=None,
'''
.. versionadded:: 2015.5.0
Apply states! This function will call highstate or state.sls based on the
arguments passed in, state.apply is intended to be the main gateway for
all state executions.
This function will call :mod:`state.highstate
<salt.modules.state.highstate>` or :mod:`state.sls
<salt.modules.state.sls>` based on the arguments passed to this function.
It exists as a more intuitive way of applying states.
CLI Example:
.. rubric:: APPLYING ALL STATES CONFIGURED IN TOP.SLS (A.K.A. :ref:`HIGHSTATE <running-highstate>`)
To apply all configured states, simply run ``state.apply``:
.. code-block:: bash
salt '*' state.apply
The following additional arguments are also accepted when applying all
states configured in top.sls:
test
Run states in test-only (dry-run) mode
pillar
Custom Pillar values, passed as a dictionary of key-value pairs
.. code-block:: bash
salt '*' state.apply test pillar='{"foo": "bar"}'
.. note::
Values passed this way will override Pillar values set via
``pillar_roots`` or an external Pillar source.
queue : False
Instead of failing immediately when another state run is in progress,
queue the new state run to begin running once the other has finished.
This option starts a new thread for each queued state run, so use this
option sparingly.
localconfig
Optionally, instead of using the minion config, load minion opts from
the file specified by this argument, and then merge them with the
options from the minion config. This functionality allows for specific
states to be run with their own custom minion configuration, including
different pillars, file_roots, etc.
.. code-block:: bash
salt '*' state.apply localconfig=/path/to/minion.yml
.. rubric:: APPLYING INDIVIDUAL SLS FILES (A.K.A. :py:func:`STATE.SLS <salt.modules.state.sls>`)
To apply individual SLS files, pass them as a comma-separated list:
.. code-block:: bash
# Run the states configured in salt://test.sls (or salt://test/init.sls)
salt '*' state.apply test
# Run the states configured in salt://test.sls (or salt://test/init.sls)
# and salt://pkgs.sls (or salt://pkgs/init.sls).
salt '*' state.apply test,pkgs
The following additional arguments are also accepted when applying
individual SLS files:
test
Run states in test-only (dry-run) mode
pillar
Custom Pillar values, passed as a dictionary of key-value pairs
.. code-block:: bash
salt '*' state.apply test pillar='{"foo": "bar"}'
.. note::
Values passed this way will override Pillar values set via
``pillar_roots`` or an external Pillar source.
queue : False
Instead of failing immediately when another state run is in progress,
queue the new state run to begin running once the other has finished.
This option starts a new thread for each queued state run, so use this
option sparingly.
concurrent : False
Execute state runs concurrently instead of serially
.. warning::
This flag is potentially dangerous. It is designed for use when
multiple state runs can safely be run at the same time. Do *not*
use this flag for performance optimization.
saltenv : None
Specify a salt fileserver environment to be used when applying states
.. versionchanged:: 0.17.0
Argument name changed from ``env`` to ``saltenv``
.. versionchanged:: 2014.7.0
If no saltenv is specified, the minion config will be checked for a
``saltenv`` parameter and if found, it will be used. If none is
found, ``base`` will be used. In prior releases, the minion config
was not checked and ``base`` would always be assumed when the
saltenv was not explicitly set.
pillarenv
Specify a Pillar environment to be used when applying states. By
default, all Pillar environments will be merged together and used.
localconfig
Optionally, instead of using the minion config, load minion opts from
the file specified by this argument, and then merge them with the
options from the minion config. This functionality allows for specific
states to be run with their own custom minion configuration, including
different pillars, file_roots, etc.
.. code-block:: bash
salt '*' state.apply test localconfig=/path/to/minion.yml
'''
if mods:
return sls(mods, **kwargs)
@ -477,14 +590,18 @@ def highstate(test=None,
Retrieve the state data from the salt master for this minion and execute it
test
Notify states to execute in test-only (dry-run) mode.
Sets the ``test`` variable in the minion ``opts`` for the duration of
the state run.
Run states in test-only (dry-run) mode
pillar
Additional pillar data to use for this function. Any pillar keys
specified here will overwrite matching keys in the Pillar data.
Custom Pillar values, passed as a dictionary of key-value pairs
.. code-block:: bash
salt '*' state.apply test pillar='{"foo": "bar"}'
.. note::
Values passed this way will override Pillar values set via
``pillar_roots`` or an external Pillar source.
.. versionchanged:: 2016.3.0
GPG-encrypted CLI Pillar data is now supported via the GPG
@ -500,14 +617,15 @@ def highstate(test=None,
Instead of failing immediately when another state run is in progress,
queue the new state run to begin running once the other has finished.
This option starts a new thread for each queued state run so use this
This option starts a new thread for each queued state run, so use this
option sparingly.
localconfig
Instead of using running minion opts, load ``localconfig`` and merge that
with the running minion opts. This functionality is intended for using
"roots" of salt directories (with their own minion config, pillars,
file_roots) to run highstate out of.
Optionally, instead of using the minion config, load minion opts from
the file specified by this argument, and then merge them with the
options from the minion config. This functionality allows for specific
states to be run with their own custom minion configuration, including
different pillars, file_roots, etc.
mock:
The mock option allows for the state run to execute without actually
@ -516,7 +634,7 @@ def highstate(test=None,
.. versionadded:: 2015.8.4
CLI Example:
CLI Examples:
.. code-block:: bash
@ -624,17 +742,21 @@ def sls(mods,
pillarenv=None,
**kwargs):
'''
Execute a set list of state files from an environment.
Execute the states in one or more SLS files
test
Notify states to execute in test-only (dry-run) mode.
Sets the ``test`` variable in the minion ``opts`` for the duration of
the state run.
Run states in test-only (dry-run) mode
pillar
Additional pillar data to use for this function. Any pillar keys
specified here will overwrite matching keys in the Pillar data.
Custom Pillar values, passed as a dictionary of key-value pairs
.. code-block:: bash
salt '*' state.apply test pillar='{"foo": "bar"}'
.. note::
Values passed this way will override Pillar values set via
``pillar_roots`` or an external Pillar source.
.. versionchanged:: 2016.3.0
GPG-encrypted CLI Pillar data is now supported via the GPG
@ -646,37 +768,47 @@ def sls(mods,
.. versionadded:: 2016.3.0
queue : ``False``
queue : False
Instead of failing immediately when another state run is in progress,
queue the new state run to begin running once the other has finished.
This option starts a new thread for each queued state run so use this
This option starts a new thread for each queued state run, so use this
option sparingly.
concurrent : False
Execute state runs concurrently instead of serially
.. warning::
This flag is potentially dangerous. It is designed for use when
multiple state runs can safely be run at the same time. Do *not*
use this flag for performance optimization.
saltenv : None
Specify a ``file_roots`` environment.
Specify a salt fileserver environment to be used when applying states
.. versionchanged:: 0.17.0
Argument name changed from ``env`` to ``saltenv``.
.. versionchanged:: 2014.7
Defaults to None. If no saltenv is specified, the minion config will
be checked for a saltenv and if found, it will be used. If none is found,
base will be used.
pillarenv : None
Specify a ``pillar_roots`` environment. By default all pillar environments
merged together will be used.
.. versionchanged:: 2014.7.0
If no saltenv is specified, the minion config will be checked for a
``saltenv`` parameter and if found, it will be used. If none is
found, ``base`` will be used. In prior releases, the minion config
was not checked and ``base`` would always be assumed when the
saltenv was not explicitly set.
concurrent:
WARNING: This flag is potentially dangerous. It is designed
for use when multiple state runs can safely be run at the same
Do not use this flag for performance optimization.
pillarenv
localconfig:
Instead of using running minion opts, load ``localconfig`` and merge that
with the running minion opts. This functionality is intended for using
"roots" of salt directories (with their own minion config, pillars,
file_roots) to run highstate out of.
Specify a Pillar environment to be used when applying states. By
default, all Pillar environments will be merged together and used.
localconfig
Optionally, instead of using the minion config, load minion opts from
the file specified by this argument, and then merge them with the
options from the minion config. This functionality allows for specific
states to be run with their own custom minion configuration, including
different pillars, file_roots, etc.
mock:
The mock option allows for the state run to execute without actually

39
salt/states/grains.py
View file

@ -226,27 +226,36 @@ def list_absent(name, value, delimiter=DEFAULT_TARGET_DELIM):
'changes': {},
'result': True,
'comment': ''}
comments = []
grain = __salt__['grains.get'](name, None)
if grain:
if isinstance(grain, list):
if value not in grain:
ret['comment'] = 'Value {1} is absent from grain {0}' \
.format(name, value)
return ret
if __opts__['test']:
ret['result'] = None
ret['comment'] = 'Value {1} in grain {0} is set to ' \
'be deleted'.format(name, value)
ret['changes'] = {'deleted': value}
return ret
__salt__['grains.remove'](name, value)
ret['comment'] = 'Value {1} was deleted from grain {0}'\
.format(name, value)
ret['changes'] = {'deleted': value}
if not isinstance(value, list):
value = [value]
for val in value:
if val not in grain:
comments.append('Value {1} is absent from '
'grain {0}'.format(name, val))
elif __opts__['test']:
ret['result'] = None
comments.append('Value {1} in grain {0} is set '
'to be deleted'.format(name, val))
if 'deleted' not in ret['changes'].keys():
ret['changes'] = {'deleted': []}
ret['changes']['deleted'].append(val)
elif val in grain:
__salt__['grains.remove'](name, val)
comments.append('Value {1} was deleted from '
'grain {0}'.format(name, val))
if 'deleted' not in ret['changes'].keys():
ret['changes'] = {'deleted': []}
ret['changes']['deleted'].append(val)
ret['comment'] = '\n'.join(comments)
return ret
else:
ret['result'] = False
ret['comment'] = 'Grain {0} is not a valid list'\
.format(name)
.format(name)
else:
ret['comment'] = 'Grain {0} does not exist'.format(name)
return ret

1
tests/integration/modules/sysmod.py
View file

@ -72,6 +72,7 @@ class SysModuleTest(integration.ModuleCase):
'nspawn.stop',
'nspawn.restart',
'lowpkg.bin_pkg_info',
'state.apply',
)
for fun in docs:

4
tests/unit/states/grains_test.py
View file

@ -976,7 +976,7 @@ class GrainsTestCase(TestCase):
value='bar')
self.assertEqual(ret['result'], True)
self.assertEqual(ret['comment'], 'Value bar was deleted from grain foo')
self.assertEqual(ret['changes'], {'deleted': 'bar'})
self.assertEqual(ret['changes'], {'deleted': ['bar']})
self.assertEqual(
grains.__grains__,
{'a': 'aval', 'foo': []})
@ -991,7 +991,7 @@ class GrainsTestCase(TestCase):
value='bar')
self.assertEqual(ret['result'], True)
self.assertEqual(ret['comment'], 'Value bar was deleted from grain foo:list')
self.assertEqual(ret['changes'], {'deleted': 'bar'})
self.assertEqual(ret['changes'], {'deleted': ['bar']})
self.assertEqual(
grains.__grains__,
{'a': 'aval', 'foo': {'list': []}})