diff --git a/docsite/rst/galaxy.rst b/docsite/rst/galaxy.rst index 5f3d2e1ff8..ccdd8eaf8b 100644 --- a/docsite/rst/galaxy.rst +++ b/docsite/rst/galaxy.rst @@ -26,7 +26,7 @@ The most obvious is downloading roles from the Ansible Galaxy website:: ansible-galaxy install username.rolename -.. _roles_path: +.. _galaxy_cli_roles_path: roles_path =============== diff --git a/docsite/rst/guide_aws.rst b/docsite/rst/guide_aws.rst index 717ee3f456..87ef29630e 100644 --- a/docsite/rst/guide_aws.rst +++ b/docsite/rst/guide_aws.rst @@ -134,11 +134,11 @@ Host Inventory `````````````` Once your nodes are spun up, you'll probably want to talk to them again. With a cloud setup, it's best to not maintain a static list of cloud hostnames -in text files. Rather, the best way to handle this is to use the ec2 dynamic inventory script. See :ref:`intro_dynamic_inventory`. +in text files. Rather, the best way to handle this is to use the ec2 dynamic inventory script. See :doc:`intro_dynamic_inventory`. This will also dynamically select nodes that were even created outside of Ansible, and allow Ansible to manage them. -See :ref:`intro_dynamic_inventory` for how to use this, then flip back over to this chapter. +See :doc:`intro_dynamic_inventory` for how to use this, then flip back over to this chapter. .. _aws_tags_and_groups: diff --git a/docsite/rst/guide_cloudstack.rst b/docsite/rst/guide_cloudstack.rst index e86badaaf6..5787a33873 100644 --- a/docsite/rst/guide_cloudstack.rst +++ b/docsite/rst/guide_cloudstack.rst @@ -1,7 +1,7 @@ CloudStack Cloud Guide ====================== -.. _introduction: +.. _cloudstack_introduction: Introduction ```````````` @@ -88,7 +88,7 @@ Use Cases The following should give you some ideas how to use the modules to provision VMs to the cloud. As always, there isn't only one way to do it. But as always: keep it simple for the beginning is always a good start. Use Case: Provisioning in a Advanced Networking CloudStack setup -+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Our CloudStack cloud has an advanced networking setup, we would like to provision web servers, which get a static NAT and open firewall ports 80 and 443. Further we provision database servers, to which we do not give any access to. For accessing the VMs by SSH we use a SSH jump host. This is how our inventory looks like: diff --git a/docsite/rst/guide_rax.rst b/docsite/rst/guide_rax.rst index 5ad806e4e5..814f9bcef8 100644 --- a/docsite/rst/guide_rax.rst +++ b/docsite/rst/guide_rax.rst @@ -1,7 +1,7 @@ Rackspace Cloud Guide ===================== -.. _introduction: +.. _rax_introduction: Introduction ```````````` diff --git a/docsite/rst/intro_configuration.rst b/docsite/rst/intro_configuration.rst index 6126fc41d0..dda07fc450 100644 --- a/docsite/rst/intro_configuration.rst +++ b/docsite/rst/intro_configuration.rst @@ -552,7 +552,7 @@ The default location is ~/ and can be changed to any writeable path:: The directory will be created if it does not already exist. -.. _roles_path: +.. _cfg_roles_path: roles_path ========== diff --git a/docsite/rst/playbooks_loops.rst b/docsite/rst/playbooks_loops.rst index b25e95941e..9cb8083b9b 100644 --- a/docsite/rst/playbooks_loops.rst +++ b/docsite/rst/playbooks_loops.rst @@ -516,14 +516,14 @@ Subsequent loops over the registered variable to inspect the results may look li -.. _loops_and_includes +.. _loops_and_includes: Loops and Includes `````````````````` -In 2.0 you are able to use with_ loops and task includes (but not playbook includes), this adds the ability to loop over the set of tasks in one shot. -There are a couple of things that you need to keep in mind, a included task that has it's own with_ loop will overwrite the value of the special `item` variable. +In 2.0 you are able to use `with_` loops and task includes (but not playbook includes), this adds the ability to loop over the set of tasks in one shot. +There are a couple of things that you need to keep in mind, a included task that has it's own `with_` loop will overwrite the value of the special `item` variable. So if you want access to both the include's `item` and the current task's `item` you should use `set_fact` to create a alias to the outer one.::