valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-07 08:58:59 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Double-backticks for formatting consistency

Browse Source
This commit is contained in:
Erik Johnson 2014-09-01 15:04:57 -05:00
parent 036e1cbeb7
commit 892a78ea1c
1 changed files with 17 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
doc/topics/pillar/index.rst
View File

@ -52,16 +52,17 @@ and has the same structure:
'*':
- packages
In the above top file, it is declared that in the 'base' environment, the glob
matching all minions will have the pillar data found in the 'packages' pillar
available to it. Assuming the 'pillar_roots' value of '/srv/pillar' taken from
above, the 'packages' pillar would be located at '/srv/pillar/packages.sls'.
In the above top file, it is declared that in the ``base`` environment, the
glob matching all minions will have the pillar data found in the ``packages``
pillar available to it. Assuming the ``pillar_roots`` value of ``/srv/salt``
taken from above, the ``packages`` pillar would be located at
``/srv/salt/packages.sls``.
Another example shows how to use other standard top matching types
to deliver specific salt pillar data to minions with different properties.
Here is an example using the 'grains' matcher to target pillars to minions
by their 'os' grain:
Here is an example using the ``grains`` matcher to target pillars to minions
by their ``os`` grain:
.. code-block:: yaml
@ -85,13 +86,14 @@ by their 'os' grain:
company: Foo Industries
The above pillar sets two key/value pairs. If a minion is running RedHat, then
the 'apache' key is set to 'httpd' and the 'git' key is set to the value of
'git'. If the minion is running Debian, those values are changed to 'apache2'
and 'git-core' respctively. All minions that have this pillar targeting to them
via a top file will have the key of 'company' with a value of 'Foo Industries'.
the ``apache`` key is set to ``httpd`` and the ``git`` key is set to the value
of ``git``. If the minion is running Debian, those values are changed to
``apache2`` and ``git-core`` respctively. All minions that have this pillar
targeting to them via a top file will have the key of ``company`` with a value
of ``Foo Industries``.
Consequently this data can be used from within modules, renderers, State SLS files, and
more via the shared pillar :ref:`dict <python2:typesmapping>`:
Consequently this data can be used from within modules, renderers, State SLS
files, and more via the shared pillar :ref:`dict <python2:typesmapping>`:
.. code-block:: yaml
@ -153,9 +155,9 @@ and a ``services.sls`` file of:
bind: named
Then a request for the ``bind`` pillar will only return 'named'; the 'bind9'
value is not available. It is better to structure your pillar files with more
hierarchy. For example your ``package.sls`` file could look like:
Then a request for the ``bind`` pillar will only return ``named``; the
``bind9`` value is not available. It is better to structure your pillar files
with more hierarchy. For example your ``package.sls`` file could look like:
.. code-block:: yaml