Merge pull request #5387 from sa2ajj/fix-docs-refs
fix various documentation xrefs
This commit is contained in:
commit
3ef228a906
8 changed files with 16 additions and 14 deletions
|
@ -37,7 +37,7 @@ It's pretty simple::
|
|||
|
||||
The run method returns results per host, grouped by whether they
|
||||
could be contacted or not. Return types are module specific, as
|
||||
expressed in the 'ansible-modules' documentation.::
|
||||
expressed in the :doc:`modules` documentation.::
|
||||
|
||||
{
|
||||
"dark" : {
|
||||
|
|
|
@ -2,8 +2,9 @@ Developing Dynamic Inventory Sources
|
|||
====================================
|
||||
|
||||
.. contents:: Topics
|
||||
:local:
|
||||
|
||||
As described in `intro_inventory_dynamic`, ansible can pull inventory information from dynamic sources, including cloud sources.
|
||||
As described in :doc:`intro_dynamic_inventory`, ansible can pull inventory information from dynamic sources, including cloud sources.
|
||||
|
||||
How do we write a new one?
|
||||
|
||||
|
|
|
@ -91,7 +91,7 @@ Where does the configuration file live and what can I configure in it?
|
|||
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
|
||||
See `intro_configuration`.
|
||||
See :doc:`intro_configuration`.
|
||||
|
||||
.. _who_would_ever_want_to_disable_cowsay_but_ok_here_is_how:
|
||||
|
||||
|
|
|
@ -122,7 +122,7 @@ Pull Configuration
|
|||
|
||||
For some the delay between refreshing host information and acting on that host information (i.e. running Ansible tasks against the hosts) may be too long. This may be the case in such scenarios where EC2 AutoScaling is being used to scale the number of instances as a result of a particular event. Such an event may require that hosts come online and are configured as soon as possible (even a 1 minute delay may be undesirable). Its possible to pre-bake machine images which contain the necessary ansible-pull script and components to pull and run a playbook via git. The machine images could be configured to run ansible-pull upon boot as part of the bootstrapping procedure.
|
||||
|
||||
More information on pull-mode playbooks can be found `here <http://www.ansibleworks.com/docs/playbooks2.html#pull-mode-playbooks>`_.
|
||||
Read :ref:`ansible-pull` for more information on pull-mode playbooks.
|
||||
|
||||
(Various developments around Ansible are also going to make this easier in the near future. Stay tuned!)
|
||||
|
||||
|
|
|
@ -21,7 +21,7 @@ Sometimes you will want to skip a particular step on a particular host. This co
|
|||
as simple as not installing a certain package if the operating system is a particular version,
|
||||
or it could be something like performing some cleanup steps if a filesystem is getting full.
|
||||
|
||||
This is easy to do in Ansible, with the `when` clause, which contains a Jinja2 expression (see `playbooks_variables`).
|
||||
This is easy to do in Ansible, with the `when` clause, which contains a Jinja2 expression (see :doc:`playbooks_variables`).
|
||||
It's actually pretty simple::
|
||||
|
||||
tasks:
|
||||
|
@ -125,7 +125,7 @@ Or with a role::
|
|||
- { role: debian_stock_config, when: ansible_os_family == 'Debian' }
|
||||
|
||||
You will note a lot of 'skipped' output by default in Ansible when using this approach on systems that don't match the criteria.
|
||||
Read up on the 'group_by' module in the `modules` docs for a more streamlined way to accomplish the same thing.
|
||||
Read up on the 'group_by' module in the :doc:`modules` docs for a more streamlined way to accomplish the same thing.
|
||||
|
||||
Conditional Imports
|
||||
```````````````````
|
||||
|
|
|
@ -335,8 +335,7 @@ Let's run a playbook using a parallelism level of 10::
|
|||
|
||||
ansible-playbook playbook.yml -f 10
|
||||
|
||||
.. _tips_and_tricks:
|
||||
|
||||
.. _ansible-pull:
|
||||
|
||||
Ansible-Pull
|
||||
````````````
|
||||
|
@ -353,6 +352,8 @@ Run 'ansible-pull --help' for details.
|
|||
|
||||
There's also a `clever playbook <https://github.com/ansible/ansible-examples/blob/master/language_features/ansible_pull.yml>`_ available to using ansible in push mode to configure ansible-pull via a crontab!
|
||||
|
||||
.. _tips_and_tricks:
|
||||
|
||||
Tips and Tricks
|
||||
```````````````
|
||||
|
||||
|
|
|
@ -382,7 +382,7 @@ Subsequent loops over the registered variable to inspect the results may look li
|
|||
Writing Your Own Iterators
|
||||
``````````````````````````
|
||||
|
||||
While you ordinarily shouldn't have to, should you wish to write your own ways to loop over arbitrary datastructures, you can read `developing_plugins` for some starter
|
||||
While you ordinarily shouldn't have to, should you wish to write your own ways to loop over arbitrary datastructures, you can read :doc:`developing_plugins` for some starter
|
||||
information. Each of the above features are implemented as plugins in ansible, so there are many implementations to reference.
|
||||
|
||||
.. seealso::
|
||||
|
|
|
@ -17,7 +17,7 @@ based on those variables.
|
|||
|
||||
Variables in Ansible are how we deal with differences between systems.
|
||||
|
||||
Once understanding variables you'll also want to dig into `playbooks_conditionals` and `playbooks_loops`.
|
||||
Once understanding variables you'll also want to dig into :doc:`playbooks_conditionals` and :doc:`playbooks_loops`.
|
||||
Useful things like the "group_by" module
|
||||
and the "when" conditional can also be used with variables, and to help manage differences between systems.
|
||||
|
||||
|
@ -49,7 +49,7 @@ a bit of a refresher.
|
|||
Often you'll want to set variables based on what groups a machine is in. For instance, maybe machines in Boston
|
||||
want to use 'boston.ntp.example.com' as an NTP server.
|
||||
|
||||
See the `intro_inventory` document for multiple ways on how to define variables in inventory.
|
||||
See the :doc:`intro_inventory` document for multiple ways on how to define variables in inventory.
|
||||
|
||||
.. _playbook_variables:
|
||||
|
||||
|
@ -232,7 +232,7 @@ Hey Wait, A YAML Gotcha
|
|||
```````````````````````
|
||||
|
||||
YAML syntax requires that if you start a value with {{ foo }} you quote the whole line, since it wants to be
|
||||
sure you aren't trying to start a YAML dictionary. This is covered on the `YAMLSyntax` page.
|
||||
sure you aren't trying to start a YAML dictionary. This is covered on the :doc:`YAMLSyntax` page.
|
||||
|
||||
This won't work::
|
||||
|
||||
|
@ -572,7 +572,7 @@ Registered Variables
|
|||
Another major use of variables is running a command and using the result of that command to save the result into a variable.
|
||||
|
||||
The value of a task being executed in ansible can be saved in a variable and used later. See some examples of this in the
|
||||
`playbooks_conditionals` chapter.
|
||||
:doc:`playbooks_conditionals` chapter.
|
||||
|
||||
While it's mentioned elsewhere in that document too, here's a quick syntax example::
|
||||
|
||||
|
@ -819,7 +819,7 @@ control you might want over values.
|
|||
First off, group variables are super powerful.
|
||||
|
||||
Site wide defaults should be defined as a 'group_vars/all' setting. Group variables are generally placed alongside
|
||||
your inventory file. They can also be returned by a dynamic inventory script (see `intro_dynamic_inventory`) or defined
|
||||
your inventory file. They can also be returned by a dynamic inventory script (see :doc:`intro_dynamic_inventory`) or defined
|
||||
in things like AnsibleWorks AWX from the UI or API::
|
||||
|
||||
---
|
||||
|
|
Loading…
Reference in a new issue