Remove more ":doc:" references from doc/* files

This commit is contained in:
rallytime 2016-12-15 15:36:44 -07:00
parent 6e32267d0c
commit 02bfe7912c
43 changed files with 202 additions and 152 deletions

View file

@ -1,3 +1,5 @@
.. _table-of-contents:
======================
Salt Table of Contents
======================

View file

@ -1,3 +1,5 @@
.. _ref-cli-salt:
========
``salt``
========

View file

@ -1,3 +1,5 @@
.. _runners:
=======
Runners
=======

View file

@ -1,3 +1,5 @@
.. _state-system-reference:
======================
State System Reference
======================
@ -25,7 +27,7 @@ configure and manage a few servers or a few thousand servers. It allows
configurations to be kept under version control.
Salt States is an extension of the Salt Modules that we discussed in the
previous :doc:`remote execution </topics/tutorials/modules>` tutorial. Instead
previous :ref:`remote execution <tutorial-remote-execution-modules>` tutorial. Instead
of calling one-off executions the state of a system can be easily defined and
then enforced.
@ -39,7 +41,7 @@ an understanding of Salt states and how to write the states is needed as well.
.. note::
States are compiled and executed only on minions that have been targeted.
To execute functions directly on masters, see :doc:`runners </ref/runners/index>`.
To execute functions directly on masters, see :ref:`runners <runners>`.
Salt SLS System
---------------

View file

@ -1,3 +1,5 @@
.. _state-providers:
===============
State Providers
===============

View file

@ -1,3 +1,5 @@
.. _proxy-minion-end-to-end-example:
====================================
Salt Proxy Minion End-to-End Example
====================================

View file

@ -155,7 +155,7 @@ systems still need to be implemented.
By default, Grains are settable through ``salt-ssh``. By
default, these grains will *not* be persisted across reboots.
See the "thin_dir" setting in :doc:`Roster documentation </topics/ssh/roster>`
See the "thin_dir" setting in :ref:`Roster documentation <ssh-roster>`
for more details.
Configuring Salt SSH
@ -167,7 +167,7 @@ the ``-c`` option to Salt SSH facilitates passing in a directory to look inside
configuration file named ``master``.
Minion Config
---------------
-------------
.. versionadded:: 2015.5.1

View file

@ -18,14 +18,14 @@ resources to learn more about state and renderers.
Contains: list of install packages, create users, transfer files, start
services, and so on.
:doc:`Pillar System <../pillar/index>`
:ref:`Pillar System <pillar>`
Contains: description of Salt's Pillar system.
:doc:`Highstate data structure <../../ref/states/highstate>`
:ref:`Highstate data structure <states-highstate>`
Contains: a dry vocabulary and technical representation of the
configuration format that states represent.
:doc:`Writing states <../../ref/states/writing>`
:ref:`Writing states <state-modules>`
Contains: a guide on how to write Salt state modules, easily extending
Salt to directly manage more software.
@ -40,13 +40,13 @@ resources to learn more about state and renderers.
templating engines, or files. Salt's configuration management system is,
under the hood, language agnostic.
:doc:`Full list of renderers <../../ref/renderers/all/index>`
:ref:`Full list of renderers <all-salt.renderers>`
Contains: a list of renderers.
YAML is one choice, but many systems are available, from
alternative templating engines to the PyDSL language for rendering
sls formulas.
:doc:`Renderers <../../ref/renderers/index>`
:ref:`Renderers <renderers>`
Contains: more information about renderers. Salt states are only
concerned with the ultimate highstate data structure, not how the
data structure was created.

View file

@ -68,7 +68,7 @@ Match the ``web-x``, ``web-y``, and ``web-z`` minions:
.. note::
For additional targeting methods please review the
:doc:`compound matchers </topics/targeting/compound>` documentation.
:ref:`compound matchers <targeting-compound>` documentation.
Regular Expressions

View file

@ -5,7 +5,7 @@ Node groups
===========
Nodegroups are declared using a compound target specification. The compound
target documentation can be found :doc:`here <compound>`.
target documentation can be found :ref:`here <targeting-compound>`.
The :conf_master:`nodegroups` master config file parameter is used to define
nodegroups. Here's an example nodegroup configuration within
@ -25,8 +25,8 @@ nodegroups. Here's an example nodegroup configuration within
.. note::
The ``L`` within group1 is matching a list of minions, while the ``G`` in
group2 is matching specific grains. See the :doc:`compound matchers
<compound>` documentation for more details.
group2 is matching specific grains. See the :ref:`compound matchers
<targeting-compound>` documentation for more details.
.. versionadded:: 2015.8.0

View file

@ -76,7 +76,7 @@ Syndic with Multimaster lets you connect a syndic to multiple masters to provide
an additional layer of redundancy in a syndic configuration.
Higher level masters should first be configured in a multimaster configuration.
See :doc:`Multimaster Tutorial </topics/tutorials/multimaster>`.
See :ref:`Multimaster Tutorial <tutorial-multi-master>`.
On the syndic, the :conf_master:`syndic_master` option is populated with
a list of the higher level masters.

View file

@ -64,7 +64,7 @@ You can check port connectivity from the minion with the nc command:
nc -v -z salt.master.ip 4505
nc -v -z salt.master.ip 4506
There is also a :doc:`firewall configuration</topics/tutorials/firewall>`
There is also a :ref:`firewall configuration<firewall>`
document that might help as well.
If you've enabled the right TCP ports on your operating system or Linux
@ -100,8 +100,8 @@ verbosity, increase the loglevel using the ``-l`` argument:
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
that minion. By contrast, ``salt`` is run from the master, and requires you to
specify the minions on which to run the command using salt's :doc:`targeting
system </topics/targeting/index>`.
specify the minions on which to run the command using salt's :ref:`targeting
system <targeting>`.
Too many open files
===================
@ -260,6 +260,6 @@ backwards compatible as possible.
Debugging the Master and Minion
===============================
A list of common :doc:`master</topics/troubleshooting/master>` and
:doc:`minion</topics/troubleshooting/minion>` troubleshooting steps provide a
A list of common :ref:`master<troubleshooting-salt-master>` and
:ref:`minion<troubleshooting-minion-salt-call>` troubleshooting steps provide a
starting point for resolving issues you may encounter.

View file

@ -1,3 +1,5 @@
.. _troubleshooting-salt-master:
===============================
Troubleshooting the Salt Master
===============================
@ -27,8 +29,8 @@ What Ports does the Master Need Open?
For the master, TCP ports 4505 and 4506 need to be open. If you've put both
your Salt master and minion in debug mode and don't see an acknowledgment
that your minion has connected, it could very well be a firewall interfering
with the connection. See our :doc:`firewall configuration
</topics/tutorials/firewall>` page for help opening the firewall on various
with the connection. See our :ref:`firewall configuration
<firewall>` page for help opening the firewall on various
platforms.
If you've opened the correct TCP ports and still aren't seeing connections,

View file

@ -28,8 +28,8 @@ What Ports does the Minion Need Open?
No ports need to be opened on the minion, as it makes outbound connections to
the master. If you've put both your Salt master and minion in debug mode and
don't see an acknowledgment that your minion has connected, it could very well
be a firewall interfering with the connection. See our :doc:`firewall
configuration </topics/tutorials/firewall>` page for help opening the firewall
be a firewall interfering with the connection. See our :ref:`firewall
configuration <firewall>` page for help opening the firewall
on various platforms.
If you have netcat installed, you can check port connectivity from the minion
@ -90,8 +90,8 @@ even more verbosity, increase the loglevel using the ``-l`` argument:
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
that minion. By contrast, ``salt`` is run from the master, and requires you to
specify the minions on which to run the command using salt's :doc:`targeting
system </topics/targeting/index>`.
specify the minions on which to run the command using salt's :ref:`targeting
system <targeting>`.
Live Python Debug Output
========================

View file

@ -41,7 +41,7 @@ Nested Dictionaries
When :ref:`dicts <python2:typesmapping>` are nested within other data
structures (particularly lists), the indentation logic sometimes changes.
Examples of where this might happen include ``context`` and ``default`` options
from the :doc:`file.managed </ref/states/all/salt.states.file>` state:
from the :mod:`file.managed <salt.states.file>` state:
.. code-block:: yaml

View file

@ -1,3 +1,5 @@
.. _cloud-controller:
==========================
Salt as a Cloud Controller
==========================
@ -122,7 +124,7 @@ on the hypervisor and is bridged to an active network device.
To use more advanced networking in Salt Virt, read the `Salt Virt
Networking` document:
:doc:`Salt Virt Networking </topics/virt/nic>`
:ref:`Salt Virt Networking <vm-nic-profiles>`
Libvirt State
-------------
@ -266,7 +268,7 @@ opened on hypervisors:
More in-depth information regarding distribution specific firewall settings can read in:
:doc:`Opening the Firewall up for Salt </topics/tutorials/firewall>`
:ref:`Opening the Firewall up for Salt <firewall>`
Salt also needs an additional flag to be turned on as well. The ``virt.tunnel``
option needs to be turned on. This flag tells Salt to run migrations securely

View file

@ -1,3 +1,5 @@
.. _tutorial-cron-with-salt:
Using cron with Salt
====================

View file

@ -1,3 +1,5 @@
.. _tutorial-esky:
======================================
Automatic Updates / Frozen Deployments
======================================

View file

@ -9,12 +9,12 @@ ESXi Proxy Minion
.. note::
This tutorial assumes basic knowledge of Salt. To get up to speed, check
out the :doc:`Salt Walkthrough </topics/tutorials/walkthrough>`.
out the :ref:`Salt Walkthrough <tutorial-salt-walk-through>`.
This tutorial also assumes a basic understanding of Salt Proxy Minions. If
you're unfamiliar with Salt's Proxy Minion system, please read the
:doc:`Salt Proxy Minion </topics/proxyminion/index>` documentation and the
:doc:`Salt Proxy Minion End-to-End Example </topics/proxyminion/demo>`
:ref:`Salt Proxy Minion <proxy-minion>` documentation and the
:ref:`Salt Proxy Minion End-to-End Example <proxy-minion-end-to-end-example>`
tutorial.
The third assumption that this tutorial makes is that you also have a
@ -33,7 +33,7 @@ proxy process that "proxies" communication from the Salt Master to the ESXi host
The master does not know or care that the ESXi 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 documentation.
:ref:`Proxy Minion <proxy-minion>` section of Salt's documentation.
Salt's ESXi Proxy Minion was added in the 2015.8.4 release of Salt.
@ -210,9 +210,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
@ -401,7 +401,7 @@ state commands against the ESXi host via a Proxy Minion: the
vSphere Execution Module
------------------------
The :doc:`Salt.modules.vsphere </ref/modules/all/salt.modules.vsphere>` is a
The :mod:`Salt.modules.vsphere <salt.modules.vsphere>` is a
standard Salt execution module that does the bulk of the work for the ESXi Proxy
Minion. If you pull up the docs for it you'll see that almost every function in
the module takes credentials (``username`` and ``password``) and a target ``host``
@ -423,7 +423,7 @@ ESXi Execution Module
In order for the Pillar information set up in the `Configuration`_ section above to
be passed to the function call in the vSphere Execution Module, the
:doc:`salt.modules.esxi </ref/modules/all/salt.modules.esxi>` execution module acts
:mod:`salt.modules.esxi <salt.modules.esxi>` execution module acts
as a "shim" between the vSphere execution module functions and the proxy process.
The "shim" takes the authentication credentials specified in the Pillar files and
@ -437,8 +437,8 @@ 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>`.
Running Remote Execution Commands
@ -463,7 +463,7 @@ The ESXi State Module functions similarly to other state modules. The "shim" pro
by the `ESXi Execution Module`_ passes the necessary ``host``, ``username``, and
``password`` credentials through, so those options don't need to be provided in the
state. Other than that, state files are written and executed just like any other
Salt state. See the :doc:`salt.modules.esxi </ref/states/all/salt.states.esxi>` state
Salt state. See the :mod:`salt.modules.esxi <salt.states.esxi>` state
for ESXi state functions.
The follow state file is an example of how to configure various pieces of an ESXi host
@ -534,7 +534,7 @@ Relevant Salt Files and Resources
- :mod:`ESXi Proxy Minion <salt.proxy.esxi>`
- :mod:`ESXi Execution Module <salt.modules.esxi>`
- :mod:`ESXi State Module <salt.states.esxi>`
- :doc:`Salt Proxy Minion Docs </topics/proxyminion/index>`
- :doc:`Salt Proxy Minion End-to-End Example </topics/proxyminion/demo>`
- :ref:`Salt Proxy Minion Docs <proxy-minion>`
- :ref:`Salt Proxy Minion End-to-End Example <proxy-minion-end-to-end-example>`
- :mod:`vSphere Execution Module <salt.modules.vsphere>`

View file

@ -7,7 +7,7 @@ Git Fileserver Backend Walkthrough
.. note::
This walkthrough assumes basic knowledge of Salt. To get up to speed, check
out the :doc:`Salt Walkthrough </topics/tutorials/walkthrough>`.
out the :ref:`Salt Walkthrough <tutorial-salt-walk-through>`.
The gitfs backend allows Salt to serve files from git repositories. It can be
enabled by adding ``git`` to the :conf_master:`fileserver_backend` list, and
@ -853,8 +853,8 @@ for documentation.
Why aren't my custom modules/states/etc. syncing to my Minions?
===============================================================
In versions 0.16.3 and older, when using the :doc:`git fileserver backend
</topics/tutorials/gitfs>`, certain versions of GitPython may generate errors
In versions 0.16.3 and older, when using the :mod:`git fileserver backend
<salt.fileserver.gitfs>`, certain versions of GitPython may generate errors
when fetching, which Salt fails to catch. While not fatal to the fetch process,
these interrupt the fileserver update that takes place before custom types are
synced, and thus interrupt the sync itself. Try disabling the git fileserver

View file

@ -1,3 +1,5 @@
.. _tutorial-halite:
=================================
Installing and Configuring Halite
=================================

View file

@ -2,35 +2,34 @@
Tutorials Index
===============
* :doc:`Salt as a Cloud Controller <cloud_controller>`
* :doc:`Using Cron with Salt <cron>`
* :doc:`Automatic Updates / Frozen Deployments <esky>`
* :doc:`ESXi Proxy Minion <esxi_proxy_minion>`
* :doc:`Opening the Firewall up for Salt <firewall>`
* :doc:`Git Fileserver Backend Walkthrough <gitfs>`
* :doc:`Halite <halite>`
* :doc:`HTTP Modules <http>`
* :doc:`Using Salt at Scale <intro_scale>`
* :doc:`LXC Management with Salt <lxc>`
* :doc:`MinionFS Backend Walkthrough <minionfs>`
* :doc:`Remote Execution Tutorial <modules>`
* :doc:`Multi-Master-PKI Tutorial With Failover <multimaster_pki>`
* :doc:`Multi Master Tutorial <multimaster>`
* :doc:`Pillar Walkthrough <pillar>`
* :doc:`Preseed Minion with Accepted Key <preseed_key>`
* :doc:`Packaging External Modules for Salt<packaging_modules>`
* :doc:`Salt Masterless Quickstart <quickstart>`
* :doc:`running salt as normal user tutorial <rooted>`
* :doc:`Salt Bootstrap <salt_bootstrap>`
* :doc:`Standalone Minion <standalone_minion>`
* :doc:`How Do I Use Salt States? <starting_states>`
* :doc:`States tutorial, part 1 - Basic Usage <states_pt1>`
* :doc:`States tutorial, part 2 - More Complex States, Requisites <states_pt2>`
* :doc:`States tutorial, part 3 - Templating, Includes, Extends <states_pt3>`
* :doc:`States tutorial, part 4 <states_pt4>`
* :doc:`How to Convert Jinja Logic to an Execution Module <jinja_to_execution-module>`
* :doc:`Using Salt with Stormpath <stormpath>`
* :doc:`Syslog-ng usage <syslog_ng-state-usage>`
* :doc:`The MacOS X (Maverick) Developer Step By Step Guide To Salt Installation <walkthrough_macosx>`
* :doc:`SaltStack Walk-through <walkthrough>`
* :doc:`Writing Salt Tests <writing_tests>`
* :ref:`Salt as a Cloud Controller <cloud-controller>`
* :ref:`Using Cron with Salt <tutorial-cron-with-salt>`
* :ref:`Automatic Updates / Frozen Deployments <tutorial-esky>`
* :ref:`ESXi Proxy Minion <tutorial-esxi-proxy>`
* :ref:`Opening the Firewall up for Salt <firewall>`
* :ref:`Git Fileserver Backend Walkthrough <tutorial-gitfs>`
* :ref:`Halite <tutorial-halite>`
* :ref:`HTTP Modules <tutorial-http>`
* :ref:`Using Salt at Scale <tutorial-salt-at-scale>`
* :ref:`LXC Management with Salt <tutorial-lxc>`
* :ref:`MinionFS Backend Walkthrough <tutorial-minionfs>`
* :ref:`Remote Execution Tutorial <tutorial-remote-execution-modules>`
* :ref:`Multi-Master-PKI Tutorial With Failover <tutorial-multi-master-pki>`
* :ref:`Multi Master Tutorial <tutorial-multi-master>`
* :ref:`Pillar Walkthrough <pillar-walk-through>`
* :ref:`Packaging External Modules for Salt<tutorial-packaging-modules>`
* :ref:`Salt Masterless Quickstart <masterless-quickstart>`
* :ref:`running salt as normal user tutorial <tutorial-rooted>`
* :ref:`Salt Bootstrap <salt-bootstrap>`
* :ref:`Standalone Minion <tutorial-standalone-minion>`
* :ref:`How Do I Use Salt States? <starting-states>`
* :ref:`States tutorial, part 1 - Basic Usage <states-tutorial>`
* :ref:`States tutorial, part 2 - More Complex States, Requisites <tutorial-states-part-2>`
* :ref:`States tutorial, part 3 - Templating, Includes, Extends <tutorial-states-part-3>`
* :ref:`States tutorial, part 4 <tutorial-states-part-4>`
* :ref:`How to Convert Jinja Logic to an Execution Module <tutorial-jinja_to_execution-module>`
* :ref:`Using Salt with Stormpath <tutorial-stormpath>`
* :ref:`Syslog-ng usage <syslog-ng-sate-usage>`
* :ref:`The MacOS X (Maverick) Developer Step By Step Guide To Salt Installation <tutorial-macos-walk-through>`
* :ref:`SaltStack Walk-through <tutorial-salt-walk-through>`
* :ref:`Writing Salt Tests <tutorial-salt-testing>`

View file

@ -1,3 +1,5 @@
.. _tutorial-salt-at-scale:
===================
Using Salt at scale
===================

View file

@ -7,7 +7,7 @@ LXC Management with Salt
.. note::
This walkthrough assumes basic knowledge of Salt. To get up to speed, check
out the :doc:`Salt Walkthrough </topics/tutorials/walkthrough>`.
out the :ref:`Salt Walkthrough <tutorial-salt-walk-through>`.
Dependencies
============

View file

@ -10,7 +10,7 @@ MinionFS Backend Walkthrough
This walkthrough assumes basic knowledge of Salt and :mod:`cp.push
<salt.modules.cp.push>`. To get up to speed, check out the
:doc:`walkthrough </topics/tutorials/walkthrough>`.
:ref:`Salt Walkthrough <tutorial-salt-walk-through>`.
Sometimes it is desirable to deploy a file located on one minion to one or more
other minions. This is supported in Salt, and can be accomplished in two parts:

View file

@ -1,3 +1,5 @@
.. _tutorial-remote-execution-modules:
=========================
Remote execution tutorial
=========================
@ -15,7 +17,7 @@ communicating with each other you can perform commands on the minion via the
salt '<target>' <function> [arguments]
.. seealso:: :doc:`salt manpage </ref/cli/salt>`
.. seealso:: :ref:`salt manpage <ref-cli-salt>`
target
------
@ -34,7 +36,7 @@ Targets can be based on minion system information using the Grains system:
salt -G 'os:Ubuntu' test.ping
.. seealso:: :doc:`Grains system </topics/targeting/grains>`
.. seealso:: :ref:`Grains system <targeting-grains>`
Targets can be filtered by regular expression:
@ -80,7 +82,7 @@ Run an arbitrary shell command:
salt '*' cmd.run 'uname -a'
.. seealso:: :doc:`the full list of modules </ref/modules/index>`
.. seealso:: :ref:`the full list of modules <all-salt_modules>`
arguments
---------

View file

@ -1,3 +1,5 @@
.. _tutorial-multi-master:
=====================
Multi Master Tutorial
=====================

View file

@ -1,3 +1,5 @@
.. _tutorial-multi-master-pki:
=======================================
Multi-Master-PKI Tutorial With Failover
=======================================

View file

@ -1,6 +1,8 @@
===============================================
.. _tutorial-packaging-modules:
===================================
Packaging External Modules for Salt
===============================================
===================================
External Modules Setuptools Entry-Points Support
================================================

View file

@ -7,7 +7,7 @@ Pillar Walkthrough
.. note::
This walkthrough assumes that the reader has already completed the initial
Salt :doc:`walkthrough </topics/tutorials/walkthrough>`.
Salt :ref:`walkthrough <tutorial-salt-walk-through>`.
Pillars are tree-like structures of data defined on the Salt Master and passed
through to minions. They allow confidential, targeted data to be securely sent
@ -346,7 +346,7 @@ information about an infrastructure is stored in a separate location.
Reference information on pillar and the external pillar interface can be found
in the Salt documentation:
:doc:`Pillar </topics/pillar/index>`
:ref:`Pillar <pillar>`
Minion Config in Pillar
=======================

View file

@ -1,3 +1,5 @@
.. _tutorial-preseed-key:
================================
Preseed Minion with Accepted Key
================================

View file

@ -1,3 +1,5 @@
.. _masterless-quickstart:
==========================
Salt Masterless Quickstart
==========================
@ -54,8 +56,8 @@ Now the salt minion will not look for a master and will assume that the local
system has all of the file and pillar resources.
Configuration which resided in the
:doc:`master configuration </ref/configuration/master>` (e.g. ``/etc/salt/master``)
should be moved to the :doc:`minion configuration </ref/configuration/minion>`
:ref:`master configuration <configuration-salt-master>` (e.g. ``/etc/salt/master``)
should be moved to the :ref:`minion configuration <configuration-salt-minion>`
since the minion does not read the master configuration.
.. note::
@ -135,5 +137,4 @@ It then examines the ``webserver.sls`` file and finds the ``apache`` state, whic
installs the Apache package.
The minion should now have Apache installed, and the next step is to begin
learning how to write
:doc:`more complex states</topics/tutorials/states_pt1>`.
learning how to write :ref:`more complex states<states-tutorial>`.

View file

@ -1,3 +1,5 @@
.. _tutorial-rooted:
====================================
running salt as normal user tutorial
====================================

View file

@ -1,3 +1,5 @@
.. _starting-states:
=========================
How Do I Use Salt States?
=========================
@ -16,7 +18,7 @@ This is often called configuration management.
.. note::
This is just the beginning of using states, make sure to read up on pillar
:doc:`Pillar </topics/tutorials/pillar>` next.
:ref:`Pillar <pillar-walk-through>` next.
It is All Just Data
@ -39,8 +41,8 @@ The Top File
============
The example SLS files in the below sections can be assigned to hosts using a
file called :strong:`top.sls`. This file is described in-depth :doc:`here
</ref/states/top>`.
file called :strong:`top.sls`. This file is described in-depth :ref:`here
<states-top>`.
Default Data - YAML
@ -330,9 +332,9 @@ templating system, and more notably, the pure Python or ``py``, ``pydsl`` &
``pyobjects`` renderers.
The ``py`` renderer allows for SLS files to be written in pure Python,
allowing for the utmost level of flexibility and power when preparing SLS
data; while the :doc:`pydsl</ref/renderers/all/salt.renderers.pydsl>` renderer
data; while the :mod:`pydsl<salt.renderers.pydsl>` renderer
provides a flexible, domain-specific language for authoring SLS data in Python;
and the :doc:`pyobjects</ref/renderers/all/salt.renderers.pyobjects>` renderer
and the :mod:`pyobjects<salt.renderers.pyobjects>` renderer
gives you a `"Pythonic"`_ interface to building state data.
.. _`Jinja2`: http://jinja.pocoo.org/
@ -346,9 +348,8 @@ gives you a `"Pythonic"`_ interface to building state data.
They can also be used in :mod:`file.managed <salt.states.file.managed>`
states, making file management much more dynamic and flexible. Some
examples for using templates in managed files can be found in the
documentation for the :doc:`file states
</ref/states/all/salt.states.file>`, as well as the :ref:`MooseFS
example<jinja-example-moosefs>` below.
documentation for the :ref:`file state <salt.states.file>`, as well as the
:ref:`MooseFS example<jinja-example-moosefs>` below.
Getting to Know the Default - yaml_jinja
@ -495,9 +496,9 @@ This is a very simple example; the first line has an SLS shebang that
tells Salt to not use the default renderer, but to use the ``py`` renderer.
Then the run function is defined, the return value from the run function
must be a Salt friendly data structure, or better known as a Salt
:doc:`HighState data structure</ref/states/highstate>`.
:ref:`HighState data structure<states-highstate>`.
Alternatively, using the :doc:`pydsl</ref/renderers/all/salt.renderers.pydsl>`
Alternatively, using the :mod:`pydsl<salt.renderers.pydsl>`
renderer, the above example can be written more succinctly as:
.. code-block:: python
@ -507,7 +508,7 @@ renderer, the above example can be written more succinctly as:
include('python', delayed=True)
state('django').pkg.installed()
The :doc:`pyobjects</ref/renderers/all/salt.renderers.pyobjects>` renderer
The :mod:`pyobjects<salt.renderers.pyobjects>` renderer
provides an `"Pythonic"`_ object based approach for building the state data.
The above example could be written as:
@ -556,4 +557,4 @@ Next Reading
With an understanding of states, the next recommendation is to become familiar
with Salt's pillar interface:
:doc:`Pillar Walkthrough </topics/tutorials/pillar>`
:ref:`Pillar Walkthrough <pillar-walk-through>`

View file

@ -6,7 +6,7 @@ States tutorial, part 1 - Basic Usage
The purpose of this tutorial is to demonstrate how quickly you can configure a
system to be managed by Salt States. For detailed information about the state
system please refer to the full :doc:`states reference </ref/states/index>`.
system please refer to the full :ref:`states reference <state-system-reference>`.
This tutorial will walk you through using Salt to configure a minion to run the
Apache HTTP server and to ensure the server is running.
@ -64,8 +64,8 @@ collection of minion matches is defined; for now simply specify all hosts
.. admonition:: Targeting minions
The expressions can use any of the targeting mechanisms used by Salt —
minions can be matched by glob, PCRE regular expression, or by :doc:`grains
</topics/targeting/grains>`. For example:
minions can be matched by glob, PCRE regular expression, or by :ref:`grains
<targeting-grains>`. For example:
.. code-block:: yaml
@ -109,8 +109,8 @@ in the :mod:`pkg state <salt.states.pkg>` module to call.
is built. Templating languages and `DSLs`_ are a dime-a-dozen and everyone
has a favorite.
Building the expected data structure is the job of Salt :doc:`renderers
</ref/renderers/index>` and they are dead-simple to write.
Building the expected data structure is the job of Salt :ref:`renderers`
and they are dead-simple to write.
In this tutorial we will be using YAML in Jinja2 templates, which is the
default format. The default can be changed by editing
@ -230,5 +230,5 @@ Next steps
==========
This tutorial focused on getting a simple Salt States configuration working.
:doc:`Part 2 <states_pt2>` will build on this example to cover more advanced
:ref:`Part 2 <tutorial-states-part-2>` will build on this example to cover more advanced
``sls`` syntax and will explore more of the states that ship with Salt.

View file

@ -1,13 +1,15 @@
.. _tutorial-states-part-2:
=========================================================
States tutorial, part 2 - More Complex States, Requisites
=========================================================
.. note::
This tutorial builds on topics covered in :doc:`part 1 <states_pt1>`. It is
This tutorial builds on topics covered in :ref:`part 1 <states-tutorial>`. It is
recommended that you begin there.
In the :doc:`last part <states_pt1>` of the Salt States tutorial we covered the
In the :ref:`last part <states-tutorial>` of the Salt States tutorial we covered the
basics of installing a package. We will now modify our ``webserver.sls`` file
to have requirements, and use even more Salt States.
@ -85,7 +87,7 @@ the ``source`` argument to the :func:`managed function
**Line 12** is a :ref:`requisite-reference` which refers to a state and an ID.
In this example, it is referring to the ``ID declaration`` from our example in
:doc:`part 1 <states_pt1>`. This declaration tells Salt not to install the HTML
:ref:`part 1 <states-tutorial>`. This declaration tells Salt not to install the HTML
file until Apache is installed.
Next, create the ``index.html`` file and save it in the ``webserver``
@ -139,10 +141,10 @@ Verify that Apache is now serving your custom HTML.
If the pkg and service names differ on your OS or distro of choice you can
specify each one separately using a :ref:`name-declaration` which explained
in :doc:`Part 3 <states_pt3>`.
in :ref:`Part 3 <tutorial-states-part-3>`.
Next steps
==========
In :doc:`part 3 <states_pt3>` we will discuss how to use includes, extends, and
In :ref:`part 3 <tutorial-states-part-3>` we will discuss how to use includes, extends, and
templating to make a more complete State Tree configuration.

View file

@ -1,11 +1,13 @@
.. _tutorial-states-part-3:
=======================================================
States tutorial, part 3 - Templating, Includes, Extends
=======================================================
.. note::
This tutorial builds on topics covered in :doc:`part 1 <states_pt1>` and
:doc:`part 2 <states_pt2>`. It is recommended that you begin there.
This tutorial builds on topics covered in :ref:`part 1 <states-tutorial>` and
:ref:`part 2 <tutorial-states-part-2>`. It is recommended that you begin there.
This part of the tutorial will cover more advanced templating and
configuration techniques for ``sls`` files.
@ -68,8 +70,8 @@ Using Grains in SLS modules
===========================
Often times a state will need to behave differently on different systems.
:doc:`Salt grains </topics/targeting/grains>` objects are made available
in the template context. The `grains` can be used from within sls modules:
:ref:`Salt grains <targeting-grains>` objects are made available in the template
context. The `grains` can be used from within sls modules:
.. code-block:: jinja
@ -170,7 +172,7 @@ Include declaration
-------------------
A previous example showed how to spread a Salt tree across several files.
Similarly, :doc:`requisites </ref/states/requisites>` span multiple files by
Similarly, :ref:`requisites` span multiple files by
using an :ref:`include-declaration`. For example:
``python/python-libs.sls:``
@ -273,6 +275,6 @@ can be rewritten without the loop:
Next steps
==========
In :doc:`part 4 <states_pt4>` we will discuss how to use salt's
In :ref:`part 4 <tutorial-states-part-4>` we will discuss how to use salt's
:conf_master:`file_roots` to set up a workflow in which states can be
"promoted" from dev, to QA, to production.

View file

@ -1,12 +1,14 @@
.. _tutorial-states-part-4:
=======================
States tutorial, part 4
=======================
.. note::
This tutorial builds on topics covered in :doc:`part 1 <states_pt1>`,
:doc:`part 2 <states_pt2>` and :doc:`part 3 <states_pt3>`. It is recommended
that you begin there.
This tutorial builds on topics covered in :ref:`part 1 <states-tutorial>`,
:ref:`part 2 <tutorial-states-part-2>`, and :ref:`part 3 <tutorial-states-part-3>`.
It is recommended that you begin there.
This part of the tutorial will show how to use salt's :conf_master:`file_roots`
to set up a workflow in which states can be "promoted" from dev, to QA, to
@ -200,7 +202,7 @@ Continue Learning
=================
The best way to continue learning about Salt States is to read through the
:doc:`reference documentation </ref/states/index>` and to look through examples
:ref:`reference documentation <state-system-reference>` and to look through examples
of existing state trees. Many pre-configured state trees
can be found on GitHub in the `saltstack-formulas`_ collection of repositories.
@ -210,5 +212,5 @@ If you have any questions, suggestions, or just want to chat with other people
who are using Salt, we have a very :ref:`active community <salt-community>`
and we'd love to hear from you.
In addition, by continuing to :doc:`part 5 <states_pt5>`, you can learn about
the powerful orchestration of which Salt is capable.
In addition, by continuing to the :ref:`Orchestrate Runner <orchestrate-runner>` docs,
you can learn about the powerful orchestration of which Salt is capable.

View file

@ -1,3 +1,5 @@
.. _tutorial-stormpath:
=========================
Using Salt with Stormpath
=========================

View file

@ -1,3 +1,5 @@
.. _tutorial-salt-walk-through:
==================
Salt in 10 Minutes
==================
@ -34,7 +36,7 @@ Installing Salt
---------------
SaltStack has been made to be very easy to install and get started. The
:doc:`installation documents </topics/installation/index>` contain instructions
:ref:`installation documents <installation>` contain instructions
for all supported platforms.
Starting Salt
@ -85,7 +87,7 @@ greatly increasing the command output:
The Salt Master needs to bind to two TCP network ports on the system. These ports
are ``4505`` and ``4506``. For more in depth information on firewalling these ports,
the firewall tutorial is available :doc:`here </topics/tutorials/firewall>`.
the firewall tutorial is available :ref:`here <firewall>`.
.. _master-dns:
@ -118,7 +120,7 @@ Setting up a Salt Minion
assumes that the minion will be connected to the master, for information on
how to run a master-less minion please see the master-less quick-start guide:
:doc:`Masterless Minion Quickstart </topics/tutorials/quickstart>`
:ref:`Masterless Minion Quickstart <masterless-quickstart>`
Now that the master can be found, start the minion in the same way as the
master; with the platform init system or via the command line directly:
@ -243,8 +245,8 @@ The ``*`` is the target, which specifies all minions.
``test.ping`` tells the minion to run the :py:func:`test.ping
<salt.modules.test.ping>` function.
In the case of ``test.ping``, ``test`` refers to a :doc:`execution module
</ref/modules/index>`. ``ping`` refers to the :py:func:`ping
In the case of ``test.ping``, ``test`` refers to a :ref:`execution module
<writing-execution-modules>`. ``ping`` refers to the :py:func:`ping
<salt.modules.test.ping>` function contained in the aforementioned ``test``
module.
@ -292,7 +294,7 @@ This will display a very large list of available functions and documentation on
them.
.. note::
Module documentation is also available :doc:`on the web </ref/modules/all/index>`.
Module documentation is also available :ref:`on the web <all-salt_modules>`.
These functions cover everything from shelling out to package management to
manipulating database servers. They comprise a powerful system management API
@ -302,14 +304,13 @@ of Salt.
.. note::
Salt comes with many plugin systems. The functions that are available via
the ``salt`` command are called :doc:`Execution Modules
</ref/modules/all/index>`.
the ``salt`` command are called :ref:`Execution Modules <all-salt_modules>`.
Helpful Functions to Know
~~~~~~~~~~~~~~~~~~~~~~~~~
The :doc:`cmd </ref/modules/all/salt.modules.cmdmod>` module contains
The :mod:`cmd <salt.modules.cmdmod>` module contains
functions to shell out on minions, such as :mod:`cmd.run
<salt.modules.cmdmod.run>` and :mod:`cmd.run_all
<salt.modules.cmdmod.run_all>`:
@ -330,7 +331,7 @@ same salt functions. This means that ``pkg.install`` will install packages via
Some custom Linux spins and derivatives of other distributions are not properly
detected by Salt. If the above command returns an error message saying that
``pkg.install`` is not available, then you may need to override the pkg
provider. This process is explained :doc:`here </ref/states/providers>`.
provider. This process is explained :ref:`here <state-providers>`.
The :mod:`network.interfaces <salt.modules.network.interfaces>` function will
list all interfaces on a minion, along with their IP addresses, netmasks, MAC
@ -380,7 +381,7 @@ minion log. More information on ``salt-call`` and how to use it can be found
Grains
~~~~~~
Salt uses a system called :doc:`Grains <../targeting/grains>` to build up
Salt uses a system called :ref:`Grains <targeting-grains>` to build up
static data about minions. This data includes information about the operating
system that is running, CPU architecture and much more. The grains system is
used throughout Salt to deliver platform data to many components and to users.
@ -396,7 +397,7 @@ function.
Targeting
~~~~~~~~~~
~~~~~~~~~
Salt allows for minions to be targeted based on a wide range of criteria. The
default targeting system uses globular expressions to match minions, hence if
@ -412,22 +413,22 @@ Regular Expressions
Grains
Target based on grains data:
:doc:`Targeting with Grains </topics/targeting/grains>`
:ref:`Targeting with Grains <targeting-grains>`
Pillar
Target based on pillar data:
:doc:`Targeting with Pillar </ref/pillar/index>`
:ref:`Targeting with Pillar <targeting-pillar>`
IP
Target based on IP address/subnet/range
Compound
Create logic to target based on multiple targets:
:doc:`Targeting with Compound </topics/targeting/compound>`
:ref:`Targeting with Compound <targeting-compound>`
Nodegroup
Target with nodegroups:
:doc:`Targeting with Nodegroup </topics/targeting/nodegroups>`
:ref:`Targeting with Nodegroup <targeting-nodegroups>`
The concepts of targets are used on the command line with Salt, but also
function in many other areas as well, including the state system and the
@ -575,10 +576,10 @@ and that it results in success.
The `require` option belongs to a family of options called `requisites`.
Requisites are a powerful component of Salt States, for more information
on how requisites work and what is available see:
:doc:`Requisites</ref/states/requisites>`
:ref:`Requisites <requisites>`
Also evaluation ordering is available in Salt as well:
:doc:`Ordering States</ref/states/ordering>`
:ref:`Ordering States<ordering>`
This new sls formula has a special name -- ``init.sls``. When an SLS formula is
named ``init.sls`` it inherits the name of the directory path that contains it.
@ -624,9 +625,9 @@ Next Reading
Two walk-throughs are specifically recommended at this point. First, a deeper
run through States, followed by an explanation of Pillar.
1. :doc:`Starting States </topics/tutorials/starting_states>`
1. :ref:`Starting States <starting-states>`
2. :doc:`Pillar Walkthrough </topics/tutorials/pillar>`
2. :ref:`Pillar Walkthrough <pillar-walk-through>`
An understanding of Pillar is extremely helpful in using States.
@ -637,10 +638,10 @@ Getting Deeper Into States
Two more in-depth States tutorials exist, which delve much more deeply into States
functionality.
1. :doc:`How Do I Use Salt States? </topics/tutorials/starting_states>`, covers much
1. :ref:`How Do I Use Salt States? <starting-states>`, covers much
more to get off the ground with States.
2. The :doc:`States Tutorial</topics/tutorials/states_pt1>` also provides a
2. The :ref:`States Tutorial<states-tutorial>` also provides a
fantastic introduction.
These tutorials include much more in-depth information including templating
@ -653,17 +654,17 @@ So Much More!
This concludes the initial Salt walk-through, but there are many more things still
to learn! These documents will cover important core aspects of Salt:
- :doc:`Pillar</topics/pillar/index>`
- :ref:`Pillar<pillar>`
- :doc:`Job Management</topics/jobs/index>`
- :ref:`Job Management<jobs>`
A few more tutorials are also available:
- :doc:`Remote Execution Tutorial</topics/tutorials/modules>`
- :ref:`Remote Execution Tutorial<writing-execution-modules>`
- :doc:`Standalone Minion</topics/tutorials/standalone_minion>`
- :ref:`Standalone Minion<tutorial-standalone-minion>`
This still is only scratching the surface, many components such as the reactor
and event systems, extending Salt, modular components and more are not covered
here. For an overview of all Salt features and documentation, look at the
:doc:`Table of Contents</contents>`.
:ref:`Table of Contents<table-of-contents>`.

View file

@ -1,3 +1,5 @@
.. _tutorial-macos-walk-through:
========================================================================
The MacOS X (Maverick) Developer Step By Step Guide To Salt Installation
========================================================================

View file

@ -37,7 +37,7 @@ Salt Virt Tutorial
A tutorial about how to get Salt Virt up and running has been added to the
tutorial section:
:doc:`Cloud Controller Tutorial </topics/tutorials/cloud_controller>`
:ref:`Cloud Controller Tutorial <cloud-controller>`
The Salt Virt Runner
====================

View file

@ -1,3 +1,5 @@
.. _vm-nic-profiles:
================================
Virtual Machine Network Profiles
================================