mirror of
https://github.com/saltstack/salt.git
synced 2025-04-17 10:10:20 +00:00
Remove ":doc:" references in salt/* files
This commit is contained in:
rallytime
parent
fc9e1dff35
commit
6e32267d0c
41 changed files with 122 additions and 124 deletions
|
|
@ -1,3 +1,5 @@
|
|||
.. _file-state-backups:
|
||||
|
||||
==================
|
||||
File State Backups
|
||||
==================
|
||||
|
|
|
|||
|
|
@ -341,6 +341,8 @@ expects to deploy fresh code via the file.recurse call. The site-code
|
|||
deployment will only be executed if the graceful-down run completes
|
||||
successfully.
|
||||
|
||||
.. _requisites-onfail:
|
||||
|
||||
onfail
|
||||
~~~~~~
|
||||
|
||||
|
|
@ -369,6 +371,8 @@ The ``onfail`` requisite is applied in the same way as ``require`` as ``watch``:
|
|||
- onfail:
|
||||
- mount: primary_mount
|
||||
|
||||
.. _requisites-onchanges:
|
||||
|
||||
onchanges
|
||||
~~~~~~~~~
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _cloud-getting-started-vmware:
|
||||
|
||||
===========================
|
||||
Getting Started With VMware
|
||||
===========================
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Getting Started With vSphere
|
|||
The :py:func:`vsphere <salt.cloud.clouds.vsphere>` cloud driver has been
|
||||
deprecated in favor of the :py:func:`vmware <salt.cloud.clouds.vmware>`
|
||||
cloud driver and will be removed in Salt 2016.11.0. Please refer to
|
||||
:doc:`Getting started with VMware </topics/cloud/vmware>` instead to get
|
||||
:ref:`Getting started with VMware <cloud-getting-started-vmware>` instead to get
|
||||
started with the configuration.
|
||||
|
||||
VMware vSphere is a management platform for virtual infrastructure and cloud
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _deprecations:
|
||||
|
||||
================
|
||||
Deprecating Code
|
||||
================
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ Install Salt (and dependencies) into the virtualenv:
|
|||
.. note:: Installing dependencies on OS X.
|
||||
|
||||
You can install needed dependencies on OS X using homebrew or macports.
|
||||
See :doc:`OS X Installation </topics/installation/osx>`
|
||||
See :ref:`OS X Installation <macos-installation>`
|
||||
|
||||
.. warning:: Installing on RedHat-based Distros
|
||||
|
||||
|
|
@ -160,7 +160,7 @@ Edit the minion config file:
|
|||
also running a non-development version of Salt, then you will have to
|
||||
change the ``master_port`` value in the minion config to match.
|
||||
|
||||
.. note:: Using `salt-call` with a :doc:`Standalone Minion </topics/tutorials/standalone_minion>`
|
||||
.. note:: Using `salt-call` with a :ref:`Standalone Minion <tutorial-standalone-minion>`
|
||||
|
||||
If you plan to run `salt-call` with this self-contained development
|
||||
environment in a masterless setup, you should invoke `salt-call` with
|
||||
|
|
@ -221,8 +221,8 @@ If you would like to log to the console instead of to the log file, remove the
|
|||
# use 'limit descriptors 2047' for c-shell
|
||||
ulimit -n 2047
|
||||
|
||||
To set file descriptors on OSX, refer to the :doc:`OS X Installation
|
||||
</topics/installation/osx>` instructions.
|
||||
To set file descriptors on OSX, refer to the :ref:`OS X Installation
|
||||
<macos-installation>` instructions.
|
||||
|
||||
|
||||
Changing Default Paths
|
||||
|
|
@ -337,7 +337,7 @@ Run the test suite with following command:
|
|||
|
||||
./setup.py test
|
||||
|
||||
See :doc:`here <tests/index>` for more information regarding the test suite.
|
||||
See :ref:`here <salt-test-suite>` for more information regarding the test suite.
|
||||
|
||||
Issue and Pull Request Labeling System
|
||||
--------------------------------------
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _macos-installation:
|
||||
|
||||
====
|
||||
OS X
|
||||
====
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _master-tops-system:
|
||||
|
||||
==================
|
||||
Master Tops System
|
||||
==================
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _release-2014-7-0:
|
||||
|
||||
=============================================
|
||||
Salt 2014.7.0 Release Notes - Codename Helium
|
||||
=============================================
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _release-2015-8-0:
|
||||
|
||||
================================================
|
||||
Salt 2015.8.0 Release Notes - Codename Beryllium
|
||||
================================================
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _yaml-idiosyncrasies:
|
||||
|
||||
===================
|
||||
YAML Idiosyncrasies
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _pillar-walk-through:
|
||||
|
||||
==================
|
||||
Pillar Walkthrough
|
||||
==================
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. syslog_ng-sate-usage:
|
||||
.. _syslog-ng-sate-usage:
|
||||
|
||||
Syslog-ng usage
|
||||
===============
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ VMware Cloud Module
|
|||
|
||||
The VMware cloud module allows you to manage VMware ESX, ESXi, and vCenter.
|
||||
|
||||
See :doc:`Getting started with VMware </topics/cloud/vmware>` to get started.
|
||||
See :ref:`Getting started with VMware <cloud-getting-started-vmware>` to get started.
|
||||
|
||||
:codeauthor: Nitin Madhok <nmadhok@clemson.edu>
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ vSphere Cloud Module
|
|||
The :py:func:`vsphere <salt.cloud.clouds.vsphere>` cloud driver has been
|
||||
deprecated in favor of the :py:func:`vmware <salt.cloud.clouds.vmware>`
|
||||
cloud driver and will be removed in Salt Carbon. Please refer to
|
||||
:doc:`Getting started with VMware </topics/cloud/vmware>` to get started
|
||||
:ref:`Getting started with VMware <cloud-getting-started-vmware>` to get started
|
||||
and convert your vsphere provider configurations to use the vmware driver.
|
||||
|
||||
The vSphere cloud module is used to control access to VMWare vSphere.
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
'''
|
||||
Glue execution module to link to the :doc:`fx2 proxymodule </ref/proxy/all/salt.proxy.fx2>`.
|
||||
Glue execution module to link to the :mod:`fx2 proxymodule <salt.proxy.fx2>`.
|
||||
|
||||
Depends: :doc:`iDRAC Remote execution module (salt.modules.dracr) </ref/modules/all/salt.modules.dracr>`
|
||||
Depends: :mod:`iDRAC Remote execution module (salt.modules.dracr) <salt.modules.dracr>`
|
||||
|
||||
For documentation on commands that you can direct to a Dell chassis via proxy,
|
||||
look in the documentation for :doc:`salt.modules.dracr </ref/modules/all/salt.modules.dracr>`.
|
||||
look in the documentation for :mod:`salt.modules.dracr <salt.modules.dracr>`.
|
||||
|
||||
This execution module calls through to a function in the fx2 proxy module
|
||||
called ``chconfig``. That function looks up the function passed in the ``cmd``
|
||||
parameter in :doc:`salt.modules.dracr </ref/modules/all/salt.modules.dracr>` and calls it.
|
||||
parameter in :mod:`salt.modules.dracr <salt.modules.dracr>` and calls it.
|
||||
|
||||
.. versionadded:: 2015.8.2
|
||||
'''
|
||||
|
|
|
|||
|
|
@ -738,8 +738,7 @@ def run(cmd,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -944,8 +943,7 @@ def shell(cmd,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -1130,8 +1128,7 @@ def run_stdout(cmd,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -1314,8 +1311,7 @@ def run_stderr(cmd,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -1498,8 +1494,7 @@ def run_all(cmd,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -1690,8 +1685,7 @@ def retcode(cmd,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -1929,8 +1923,7 @@ def script(source,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -2157,8 +2150,7 @@ def script_retcode(source,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -2426,8 +2418,7 @@ def run_chroot(root,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -2703,8 +2694,7 @@ def powershell(cmd,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -2875,8 +2865,7 @@ def run_bg(cmd,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
|
|||
|
|
@ -116,8 +116,7 @@ def _get_repo_options_env(env):
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
'''
|
||||
env_options = ''
|
||||
|
|
@ -159,8 +158,7 @@ def _get_repo_dists_env(env):
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
'''
|
||||
# env key with tuple of control information for handling input env dictionary
|
||||
|
|
@ -237,8 +235,7 @@ def _create_pbuilders(env):
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
'''
|
||||
home = os.path.expanduser('~')
|
||||
|
|
|
|||
|
|
@ -1,21 +1,19 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
'''
|
||||
Glues the VMware vSphere Execution Module to the VMware ESXi Proxy Minions to the
|
||||
:doc:`esxi proxymodule </ref/proxy/all/salt.proxy.esxi>`.
|
||||
:mod:`esxi proxymodule <salt.proxy.esxi>`.
|
||||
|
||||
.. versionadded:: 2015.8.4
|
||||
|
||||
Depends: :doc:`vSphere Remote Execution Module (salt.modules.vsphere)
|
||||
</ref/modules/all/salt.modules.vsphere>`
|
||||
Depends: :mod:`vSphere Remote Execution Module (salt.modules.vsphere)
|
||||
<salt.modules.vsphere>`
|
||||
|
||||
For documentation on commands that you can direct to an ESXi host via proxy,
|
||||
look in the documentation for :doc:`salt.modules.vsphere
|
||||
</ref/modules/all/salt.modules.vsphere>`.
|
||||
look in the documentation for :mod:`salt.modules.vsphere <salt.modules.vsphere>`.
|
||||
|
||||
This execution module calls through to a function in the ESXi proxy module
|
||||
called ``ch_config``, which looks up the function passed in the ``command``
|
||||
parameter in :doc:`salt.modules.vsphere </ref/modules/all/salt.modules.vsphere>`
|
||||
and calls it.
|
||||
parameter in :mod:`salt.modules.vsphere <salt.modules.vsphere>` and calls it.
|
||||
|
||||
To execute commands with an ESXi Proxy Minion using the vSphere Execution Module,
|
||||
use the ``esxi.cmd <vsphere-function-name>`` syntax. Both args and kwargs needed
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
'''
|
||||
Use the :doc:`Salt Event System </topics/event/index>` to fire events from the
|
||||
Use the :ref:`Salt Event System <events>` to fire events from the
|
||||
master to the minion and vice-versa.
|
||||
'''
|
||||
from __future__ import absolute_import
|
||||
|
|
|
|||
|
|
@ -5166,8 +5166,8 @@ def list_backups(path, limit=None):
|
|||
'''
|
||||
.. versionadded:: 0.17.0
|
||||
|
||||
Lists the previous versions of a file backed up using Salt's :doc:`file
|
||||
state backup </ref/states/backup_mode>` system.
|
||||
Lists the previous versions of a file backed up using Salt's :ref:`file
|
||||
state backup <file-state-backups>` system.
|
||||
|
||||
path
|
||||
The path on the minion to check for backups
|
||||
|
|
@ -5237,8 +5237,8 @@ list_backup = salt.utils.alias_function(list_backups, 'list_backup')
|
|||
|
||||
def list_backups_dir(path, limit=None):
|
||||
'''
|
||||
Lists the previous versions of a directory backed up using Salt's :doc:`file
|
||||
state backup </ref/states/backup_mode>` system.
|
||||
Lists the previous versions of a directory backed up using Salt's :ref:`file
|
||||
state backup <file-state-backups>` system.
|
||||
|
||||
path
|
||||
The directory on the minion to check for backups
|
||||
|
|
@ -5301,7 +5301,7 @@ def restore_backup(path, backup_id):
|
|||
.. versionadded:: 0.17.0
|
||||
|
||||
Restore a previous version of a file that was backed up using Salt's
|
||||
:doc:`file state backup </ref/states/backup_mode>` system.
|
||||
:ref:`file state backup <file-state-backups>` system.
|
||||
|
||||
path
|
||||
The path on the minion to check for backups
|
||||
|
|
@ -5363,7 +5363,7 @@ def delete_backup(path, backup_id):
|
|||
.. versionadded:: 0.17.0
|
||||
|
||||
Delete a previous version of a file that was backed up using Salt's
|
||||
:doc:`file state backup </ref/states/backup_mode>` system.
|
||||
:ref:`file state backup <file-state-backups>` system.
|
||||
|
||||
path
|
||||
The path on the minion to check for backups
|
||||
|
|
|
|||
|
|
@ -4,8 +4,8 @@ Control Modjk via the Apache Tomcat "Status" worker
|
|||
(http://tomcat.apache.org/connectors-doc/reference/status.html)
|
||||
|
||||
Below is an example of the configuration needed for this module. This
|
||||
configuration data can be placed either in :doc:`grains
|
||||
</topics/targeting/grains>` or :doc:`pillar </topics/pillar/index>`.
|
||||
configuration data can be placed either in :ref:`grains
|
||||
<targeting-grains>` or :ref:`pillar <salt-pillars>`.
|
||||
|
||||
If using grains, this can be accomplished :ref:`statically
|
||||
<static-custom-grains>` or via a :ref:`grain module <writing-grains>`.
|
||||
|
|
|
|||
|
|
@ -614,10 +614,9 @@ def set_(device, minor, flag, state):
|
|||
'''
|
||||
Changes a flag on the partition with number <minor>.
|
||||
|
||||
A flag can be either "on" or "off" (make sure to use proper quoting, see `YAML Idiosyncrasies`_). Some or all of these flags will be
|
||||
available, depending on what disk label you are using.
|
||||
|
||||
.. _`YAML Idiosyncrasies`: https://docs.saltstack.com/en/latest/topics/troubleshooting/yaml_idiosyncrasies.html#true-false-yes-no-on-off
|
||||
A flag can be either "on" or "off" (make sure to use proper quoting, see
|
||||
:ref:`YAML Idiosyncrasies <yaml-idiosyncrasies>`). Some or all of these
|
||||
flags will be available, depending on what disk label you are using.
|
||||
|
||||
Valid flags are: bios_grub, legacy_boot, boot, lba, root, swap, hidden, raid,
|
||||
LVM, PALO, PREP, DIAG
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Wrapper for rsync
|
|||
|
||||
.. versionadded:: 2014.1.0
|
||||
|
||||
This data can also be passed into :doc:`pillar </topics/tutorials/pillar>`.
|
||||
This data can also be passed into :ref:`pillar <pillar-walk-through>`.
|
||||
Options passed into opts will overwrite options passed into pillar.
|
||||
'''
|
||||
from __future__ import absolute_import
|
||||
|
|
|
|||
|
|
@ -4,8 +4,8 @@ Use a git repository as a Pillar source
|
|||
---------------------------------------
|
||||
|
||||
.. note::
|
||||
This external pillar has been rewritten for the :doc:`2015.8.0
|
||||
</topics/releases/2015.8.0>` release. The old method of configuring this
|
||||
This external pillar has been rewritten for the :ref:`2015.8.0
|
||||
<release-2015-8-0>` release. The old method of configuring this
|
||||
external pillar will be maintained for a couple releases, allowing time for
|
||||
configurations to be updated to reflect the new usage.
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ the repo's URL. Configuration details can be found below.
|
|||
Configuring git_pillar for Salt releases before 2015.8.0
|
||||
========================================================
|
||||
|
||||
For Salt releases earlier than :doc:`2015.8.0 </topics/releases/2015.8.0>`,
|
||||
For Salt releases earlier than :ref:`2015.8.0 <release-2015-8-0>`,
|
||||
GitPython is the only supported provider for git_pillar. Individual
|
||||
repositories can be configured under the :conf_master:`ext_pillar`
|
||||
configuration parameter like so:
|
||||
|
|
@ -67,8 +67,8 @@ configuration parameter like so:
|
|||
- git: master https://gitserver/git-pillar.git root=subdirectory
|
||||
|
||||
The repository is specified in the format ``<branch> <repo_url>``, with an
|
||||
optional ``root`` parameter (added in the :doc:`2014.7.0
|
||||
</topics/releases/2014.7.0>` release) which allows the pillar SLS files to be
|
||||
optional ``root`` parameter (added in the :ref:`2014.7.0
|
||||
<release-2014-7-0>` release) which allows the pillar SLS files to be
|
||||
served up from a subdirectory (similar to :conf_master:`gitfs_root` in gitfs).
|
||||
|
||||
To use more than one branch from the same repo, multiple lines must be
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Proxy minion for managing a Chronos cluster.
|
|||
Dependencies
|
||||
------------
|
||||
|
||||
- :doc:`chronos execution module (salt.modules.chronos) </ref/modules/all/salt.modules.chronos>`
|
||||
- :mod:`chronos execution module (salt.modules.chronos) <salt.modules.chronos>`
|
||||
|
||||
Pillar
|
||||
------
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ a minion process that "proxies" communication from the Salt Master. The master
|
|||
does not know nor care that the target is not a "real" Salt Minion.
|
||||
|
||||
More in-depth conceptual reading on Proxy Minions can be found in the
|
||||
:doc:`Proxy Minion </topics/proxyminion/index>` section of Salt's
|
||||
:ref:`Proxy Minion <proxy-minion>` section of Salt's
|
||||
documentation.
|
||||
|
||||
|
||||
|
|
@ -130,9 +130,9 @@ one password in this list is required.
|
|||
The proxy integration will try the passwords listed in order. It is
|
||||
configured this way so you can have a regular password and the password you
|
||||
may be updating for an ESXi host either via the
|
||||
:doc:`vsphere.update_host_password </ref/modules/all/salt.modules.vsphere>`
|
||||
:mod:`vsphere.update_host_password <salt.modules.vsphere.update_host_password>`
|
||||
execution module function or via the
|
||||
:doc:`esxi.password_present </ref/modules/all/salt.states.esxi>` state
|
||||
:mod:`esxi.password_present <salt.states.esxi.password_present>` state
|
||||
function. This way, after the password is changed, you should not need to
|
||||
restart the proxy minion--it should just pick up the the new password
|
||||
provided in the list. You can then change pillar at will to move that
|
||||
|
|
@ -225,7 +225,7 @@ Note that you don't need to provide credentials or an ip/hostname. Salt
|
|||
knows to use the credentials you stored in Pillar.
|
||||
|
||||
It's important to understand how this particular proxy works.
|
||||
:doc:`Salt.modules.vsphere </ref/modules/all/salt.modules.vsphere>` is a
|
||||
:mod:`Salt.modules.vsphere <salt.modules.vsphere>` is a
|
||||
standard Salt execution module. If you pull up the docs for it you'll see
|
||||
that almost every function in the module takes credentials and a target
|
||||
host. When credentials and a host aren't passed, Salt runs commands
|
||||
|
|
@ -243,15 +243,15 @@ Proxy Minion.
|
|||
|
||||
Because of the presence of the shim, to lookup documentation for what
|
||||
functions you can use to interface with the ESXi host, you'll want to
|
||||
look in :doc:`salt.modules.vsphere </ref/modules/all/salt.modules.vsphere>`
|
||||
instead of :doc:`salt.modules.esxi </ref/modules/all/salt.modules.esxi>`.
|
||||
look in :mod:`salt.modules.vsphere <salt.modules.vsphere>`
|
||||
instead of :mod:`salt.modules.esxi <salt.modules.esxi>`.
|
||||
|
||||
|
||||
States
|
||||
------
|
||||
|
||||
Associated states are thoroughly documented in
|
||||
:doc:`salt.states.esxi </ref/states/all/salt.states.esxi>`. Look there
|
||||
:mod:`salt.states.esxi <salt.states.esxi>`. Look there
|
||||
to find an example structure for Pillar as well as an example ``.sls`` file
|
||||
for standing up an ESXi host from scratch.
|
||||
|
||||
|
|
@ -376,9 +376,9 @@ def shutdown():
|
|||
def ch_config(cmd, *args, **kwargs):
|
||||
'''
|
||||
This function is called by the
|
||||
:doc:`salt.modules.esxi.cmd </ref/modules/all/salt.modules.esxi>` shim.
|
||||
:mod:`salt.modules.esxi.cmd <salt.modules.esxi.cmd>` shim.
|
||||
It then calls whatever is passed in ``cmd`` inside the
|
||||
:doc:`salt.modules.vsphere </ref/modules/all/salt.modules.vsphere>` module.
|
||||
:mod:`salt.modules.vsphere <salt.modules.vsphere>` module.
|
||||
Passes the return through from the vsphere module.
|
||||
|
||||
cmd
|
||||
|
|
|
|||
|
|
@ -12,9 +12,9 @@ and above)
|
|||
Dependencies
|
||||
------------
|
||||
|
||||
- :doc:`iDRAC Remote execution module (salt.modules.dracr) </ref/modules/all/salt.modules.dracr>`
|
||||
- :doc:`Chassis command shim (salt.modules.chassis) </ref/modules/all/salt.modules.chassis>`
|
||||
- :doc:`Dell Chassis States (salt.states.dellchassis) </ref/states/all/salt.states.dellchassis>`
|
||||
- :mod:`iDRAC Remote execution module (salt.modules.dracr) <salt.modules.dracr>`
|
||||
- :mod:`Chassis command shim (salt.modules.chassis) <salt.modules.chassis>`
|
||||
- :mod:`Dell Chassis States (salt.states.dellchassis) <salt.states.dellchassis>`
|
||||
- Dell's ``racadm`` command line interface to CMC and iDRAC devices.
|
||||
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ process that "proxies" communication from the salt-master. The master does not
|
|||
know nor care that the target is not a real minion.
|
||||
|
||||
More in-depth conceptual reading on Proxy Minions can be found
|
||||
:doc:`in the Proxy Minion section </topics/proxyminion/index>` of
|
||||
:ref:`in the Proxy Minion section <proxy-minion>` of
|
||||
Salt's documentation.
|
||||
|
||||
To configure this integration, follow these steps:
|
||||
|
|
@ -144,7 +144,7 @@ Note that you don't need to provide credentials or an ip/hostname. Salt knows
|
|||
to use the credentials you stored in Pillar.
|
||||
|
||||
It's important to understand how this particular proxy works.
|
||||
:doc:`Salt.modules.dracr </ref/modules/all/salt.modules.dracr>` is a standard Salt execution
|
||||
:mod:`Salt.modules.dracr <salt.modules.dracr>` is a standard Salt execution
|
||||
module. If you pull up the docs for it you'll see that almost every function
|
||||
in the module takes credentials and a target host. When credentials and a host
|
||||
aren't passed, Salt runs ``racadm`` against the local machine. If you wanted
|
||||
|
|
@ -160,13 +160,13 @@ credentials and hostname to be pulled from the pillar section for this proxy min
|
|||
|
||||
Because of the presence of the shim, to lookup documentation for what
|
||||
functions you can use to interface with the chassis, you'll want to
|
||||
look in :doc:`salt.modules.dracr </ref/modules/all/salt.modules.dracr>` instead
|
||||
of :doc:`salt.modules.chassis </ref/modules/all/salt.modules.chassis>`.
|
||||
look in :mod:`salt.modules.dracr <salt.modules.dracr>` instead
|
||||
of :mod:`salt.modules.chassis <salt.modules.chassis>`.
|
||||
|
||||
States
|
||||
------
|
||||
|
||||
Associated states are thoroughly documented in :doc:`salt.states.dellchassis </ref/states/all/salt.states.dellchassis>`.
|
||||
Associated states are thoroughly documented in :mod:`salt.states.dellchassis <salt.states.dellchassis>`.
|
||||
Look there to find an example structure for pillar as well as an example
|
||||
``.sls`` file for standing up a Dell Chassis from scratch.
|
||||
|
||||
|
|
@ -318,9 +318,9 @@ def find_credentials():
|
|||
|
||||
def chconfig(cmd, *args, **kwargs):
|
||||
'''
|
||||
This function is called by the :doc:`salt.modules.chassis.cmd </ref/modules/all/salt.modules.chassis>`
|
||||
This function is called by the :mod:`salt.modules.chassis.cmd <salt.modules.chassis.cmd>`
|
||||
shim. It then calls whatever is passed in ``cmd``
|
||||
inside the :doc:`salt.modules.dracr </ref/modules/all/salt.modules.dracr>`
|
||||
inside the :mod:`salt.modules.dracr <salt.modules.dracr>`
|
||||
module.
|
||||
|
||||
:param cmd: The command to call inside salt.modules.dracr
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Proxy minion for managing a Marathon cluster.
|
|||
Dependencies
|
||||
------------
|
||||
|
||||
- :doc:`marathon execution module (salt.modules.marathon) </ref/modules/all/salt.modules.marathon>`
|
||||
- :mod:`marathon execution module (salt.modules.marathon) <salt.modules.marathon>`
|
||||
|
||||
Pillar
|
||||
------
|
||||
|
|
|
|||
|
|
@ -113,11 +113,10 @@ two examples `ls -la` is the `name` argument.
|
|||
|
||||
Finally, a :ref:`requisite-declaration` object with its
|
||||
:ref:`requisite-reference`'s can be created by invoking one of the
|
||||
requisite methods (see :doc:`State Requisites
|
||||
</ref/states/requisites>`) on either a :ref:`function-declaration`
|
||||
object or a :ref:`state-declaration` object. The return value of a
|
||||
requisite call is also a :ref:`function-declaration` object, so you
|
||||
can chain several requisite calls together.
|
||||
requisite methods (see :ref:`State Requisites <requisites>`) on either a
|
||||
:ref:`function-declaration` object or a :ref:`state-declaration` object.
|
||||
The return value of a requisite call is also a :ref:`function-declaration`
|
||||
object, so you can chain several requisite calls together.
|
||||
|
||||
Arguments to a requisite call can be a list of :ref:`state-declaration` objects
|
||||
and/or a set of keyword arguments whose names are state modules and values are
|
||||
|
|
@ -286,7 +285,7 @@ sls module as if it was never defined.
|
|||
|
||||
Integration with the stateconf renderer
|
||||
-----------------------------------------
|
||||
The :doc:`salt.renderers.stateconf` renderer offers a few interesting features that
|
||||
The :mod:`salt.renderers.stateconf` renderer offers a few interesting features that
|
||||
can be leveraged by the `pydsl` renderer. In particular, when using with the `pydsl`
|
||||
renderer, we are interested in `stateconf`'s sls namespacing feature (via dot-prefixed
|
||||
id declarations), as well as, the automatic `start` and `goal` states generation.
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ is that :mod:`cmd.run <salt.states.cmd.run>` states are run each time the SLS
|
|||
file that contains them is applied. If it is more desirable to have a command
|
||||
that only runs after some other state changes, then :mod:`cmd.wait
|
||||
<salt.states.cmd.wait>` does just that. :mod:`cmd.wait <salt.states.cmd.wait>`
|
||||
is designed to :doc:`watch </ref/states/requisites>` other states, and is
|
||||
is designed to :ref:`watch <requisites-watch>` other states, and is
|
||||
executed when the state it is watching changes. Example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
|
@ -180,7 +180,7 @@ executed when the state it is watching changes. Example:
|
|||
function, which is called by ``watch`` on changes.
|
||||
|
||||
``cmd.wait`` will be deprecated in future due to the confusion it causes. The
|
||||
preferred format is using the :doc:`onchanges Requisite </ref/states/requisites>`, which
|
||||
preferred format is using the :ref:`onchanges Requisite <requisites-onchanges>`, which
|
||||
works on ``cmd.run`` as well as on any other state. The example would then look as follows:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
|
@ -438,8 +438,7 @@ def wait(name,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -573,8 +572,7 @@ def wait_script(name,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies.>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -691,8 +689,7 @@ def run(name,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
@ -932,8 +929,7 @@ def script(name,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
Variables as values are not evaluated. So $PATH in the following
|
||||
example is a literal '$PATH':
|
||||
|
|
|
|||
|
|
@ -34,9 +34,8 @@ set_file
|
|||
'ferm/enable': {'type': 'boolean', 'value': True}
|
||||
|
||||
.. note::
|
||||
Due to how PyYAML imports nested dicts (see :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`), the values in the ``data``
|
||||
dict must be indented four spaces instead of two.
|
||||
Due to how PyYAML imports nested dicts (see :ref:`here <yaml-idiosyncrasies>`),
|
||||
the values in the ``data`` dict must be indented four spaces instead of two.
|
||||
'''
|
||||
from __future__ import absolute_import
|
||||
import salt.ext.six as six
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ About
|
|||
This state module was written to be used in conjunction with Salt's
|
||||
:mod:`ESXi Proxy Minion <salt.proxy.esxi>`. For a tutorial on how to use Salt's
|
||||
ESXi Proxy Minion, please refer to the
|
||||
:doc:`ESXi Proxy Minion Tutorial </topics/tutorials/esxi_proxy_minion>` for
|
||||
:ref:`ESXi Proxy Minion Tutorial <tutorial-esxi-proxy>` for
|
||||
configuration examples, dependency installation instructions, how to run remote
|
||||
execution functions against ESXi hosts via a Salt Proxy Minion, and a larger state
|
||||
example.
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ salt fileserver. Here's an example:
|
|||
|
||||
Salt supports backing up managed files via the backup option. For more
|
||||
details on this functionality please review the
|
||||
:doc:`backup_mode documentation </ref/states/backup_mode>`.
|
||||
:ref:`backup_mode documentation <file-state-backups>`.
|
||||
|
||||
The ``source`` parameter can also specify a file in another Salt environment.
|
||||
In this example ``foo.conf`` in the ``dev`` environment will be used instead.
|
||||
|
|
|
|||
|
|
@ -5,14 +5,14 @@ Manage modjk workers
|
|||
|
||||
Send commands to a :strong:`modjk` load balancer via the peer system.
|
||||
|
||||
This module can be used with the :doc:`prereq </ref/states/requisites>`
|
||||
This module can be used with the :ref:`prereq <requisites-prereq>`
|
||||
requisite to remove/add the worker from the load balancer before
|
||||
deploying/restarting service.
|
||||
|
||||
Mandatory Settings:
|
||||
|
||||
- The minion needs to have permission to publish the :strong:`modjk.*`
|
||||
functions (see :doc:`here </ref/peer>` for information on configuring
|
||||
functions (see :ref:`here <peer>` for information on configuring
|
||||
peer publishing permissions)
|
||||
|
||||
- The modjk load balancer must be configured as stated in the :strong:`modjk`
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ state:
|
|||
|
||||
Note that this example is probably unnecessary to use in practice, since the
|
||||
``mine_functions`` and ``mine_interval`` config parameters can be used to
|
||||
schedule updates for the mine (see :doc:`here </topics/mine/index>` for more
|
||||
schedule updates for the mine (see :ref:`here <salt-mine>` for more
|
||||
info).
|
||||
|
||||
It is sometimes desirable to trigger a function call after a state is executed,
|
||||
|
|
@ -116,11 +116,11 @@ def wait(name, **kwargs):
|
|||
return ``True`` but not actually execute, unless one of the following
|
||||
two things happens:
|
||||
|
||||
1. The state has a :doc:`watch requisite </ref/states/requisites>`, and
|
||||
1. The state has a :ref:`watch requisite <requisites-watch>`, and
|
||||
the state which it is watching changes.
|
||||
|
||||
2. Another state has a :doc:`watch_in requisite
|
||||
</ref/states/requisites>` which references this state, and the state
|
||||
2. Another state has a :ref:`watch_in requisite
|
||||
<requisites-watch-in>` which references this state, and the state
|
||||
wth the ``watch_in`` changes.
|
||||
'''
|
||||
return {'name': name,
|
||||
|
|
|
|||
|
|
@ -142,8 +142,7 @@ def built(name,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other) PyYAML
|
||||
idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
idiosyncrasies can be found :ref:`here <yaml-idiosyncrasies>`.
|
||||
|
||||
results
|
||||
The names of the expected rpms that will be built
|
||||
|
|
@ -321,8 +320,8 @@ def repo(name,
|
|||
**no**, **on**, **off**, **true**, and **false** are all loaded as
|
||||
boolean ``True`` and ``False`` values, and must be enclosed in
|
||||
quotes to be used as strings. More info on this (and other)
|
||||
``PyYAML`` idiosyncrasies can be found :doc:`here
|
||||
</topics/troubleshooting/yaml_idiosyncrasies>`.
|
||||
``PyYAML`` idiosyncrasies can be found :ref:`here
|
||||
<yaml-idiosyncrasies>`.
|
||||
|
||||
Use of ``OPTIONS`` on some platforms, for example:
|
||||
``ask-passphrase``, will require ``gpg-agent`` or similar to cache
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ service, then set the reload value to True:
|
|||
.. note::
|
||||
|
||||
More details regarding ``watch`` can be found in the
|
||||
:doc:`Requisites </ref/states/requisites>` documentation.
|
||||
:ref:`Requisites <requisites>` documentation.
|
||||
|
||||
'''
|
||||
|
||||
|
|
@ -316,7 +316,7 @@ def running(name, enable=None, sig=None, init_delay=None, **kwargs):
|
|||
``watch`` can be used with service.running to restart a service when
|
||||
another state changes ( example: a file.managed state that creates the
|
||||
service's config file ). More details regarding ``watch`` can be found
|
||||
in the :doc:`Requisites </ref/states/requisites>` documentation.
|
||||
in the :ref:`Requisites <requisites>` documentation.
|
||||
'''
|
||||
ret = {'name': name,
|
||||
'changes': {},
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ If the service module is available on the computers, users should use that.
|
|||
|
||||
Users can generate syslog-ng configuration with
|
||||
:mod:`syslog_ng.config <salt.states.syslog_ng.config>` function.
|
||||
For more information see :doc:`syslog-ng state usage </topics/tutorials/syslog_ng-state-usage>`.
|
||||
For more information see :ref:`syslog-ng state usage <syslog-ng-sate-usage>`.
|
||||
|
||||
Syslog-ng configuration file format
|
||||
-----------------------------------
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Read tops data from a reclass database
|
|||
|
||||
.. |reclass| replace:: **reclass**
|
||||
|
||||
This :doc:`master_tops </topics/master_tops/index>` plugin provides access to
|
||||
This :ref:`master_tops <master-tops-system>` plugin provides access to
|
||||
the |reclass| database, such that state information (top data) are retrieved
|
||||
from |reclass|.
|
||||
|
||||
|
|
|
|||
|
|
@ -2256,7 +2256,7 @@ def kwargs_warn_until(kwargs,
|
|||
This function is used to help deprecate unused legacy ``**kwargs`` that
|
||||
were added to function parameters lists to preserve backwards compatibility
|
||||
when removing a parameter. See
|
||||
:doc:`the deprecation development docs </topics/development/deprecations>`
|
||||
:ref:`the deprecation development docs <deprecations>`
|
||||
for the modern strategy for deprecating a function parameter.
|
||||
|
||||
:param kwargs: The caller's ``**kwargs`` argument value (a ``dict``).
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue