diff --git a/docs/docsite/rst/dev_guide/developing_module_utilities.rst b/docs/docsite/rst/dev_guide/developing_module_utilities.rst index 62ce781cc3a..240da8d11b7 100644 --- a/docs/docsite/rst/dev_guide/developing_module_utilities.rst +++ b/docs/docsite/rst/dev_guide/developing_module_utilities.rst @@ -72,6 +72,6 @@ please see the `source code for module_utils `_ to aid in writing code compatible with both Python 2 and Python 3 +- ``six/__init__.py`` - Bundled copy of the `Six Python library `_ to aid in writing code compatible with both Python 2 and Python 3 - ``splitter.py`` - String splitting and manipulation utilities for working with Jinja2 templates - ``urls.py`` - Utilities for working with http and https requests diff --git a/docs/docsite/rst/dev_guide/developing_modules_best_practices.rst b/docs/docsite/rst/dev_guide/developing_modules_best_practices.rst index ad56d6338e8..60251809f66 100644 --- a/docs/docsite/rst/dev_guide/developing_modules_best_practices.rst +++ b/docs/docsite/rst/dev_guide/developing_modules_best_practices.rst @@ -160,7 +160,8 @@ Ansible conventions offer a predictable user interface across all modules, playb * Implement declarative operations (not CRUD) so the user can ignore existing state and focus on final state. For example, use ``started/stopped``, ``present/absent``. * Strive for a consistent final state (aka idempotency). If running your module twice in a row against the same system would result in two different states, see if you can redesign or rewrite to achieve consistent final state. If you can't, document the behavior and the reasons for it. * Provide consistent return values within the standard Ansible return structure, even if NA/None are used for keys normally returned under other options. -* Follow additional guidelines that apply to families of modules if applicable. For example, AWS modules should follow `the Amazon guidelines `_ +* Follow additional guidelines that apply to families of modules if applicable. For example, AWS modules should follow the :ref:`Amazon development checklist `. + Module Security =============== diff --git a/docs/docsite/rst/dev_guide/developing_modules_checklist.rst b/docs/docsite/rst/dev_guide/developing_modules_checklist.rst index 6a3f39b0e7d..0ec2811e73a 100644 --- a/docs/docsite/rst/dev_guide/developing_modules_checklist.rst +++ b/docs/docsite/rst/dev_guide/developing_modules_checklist.rst @@ -40,5 +40,5 @@ Other checklists ================ * :ref:`Tips for module development `. -* `Amazon development checklist `_. +* :ref:`Amazon development checklist `. * :ref:`Windows development checklist `. diff --git a/docs/docsite/rst/dev_guide/developing_python_3.rst b/docs/docsite/rst/dev_guide/developing_python_3.rst index bdc91483c50..23b9541656b 100644 --- a/docs/docsite/rst/dev_guide/developing_python_3.rst +++ b/docs/docsite/rst/dev_guide/developing_python_3.rst @@ -306,10 +306,10 @@ We do not prefix the text strings instead because we only operate on byte strings at the borders, so there are fewer variables that need bytes than text. -Import Ansible's bundled ``python-six`` library +Import Ansible's bundled Python ``six`` library ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The third-party `python-six `_ library exists +The third-party Python `six `_ library exists to help projects create code that runs on both Python 2 and Python 3. Ansible includes a version of the library in module_utils so that other modules can use it without requiring that it is installed on the remote system. To make use of diff --git a/docs/docsite/rst/galaxy/dev_guide.rst b/docs/docsite/rst/galaxy/dev_guide.rst index 0e55046f1a3..816be220bfe 100644 --- a/docs/docsite/rst/galaxy/dev_guide.rst +++ b/docs/docsite/rst/galaxy/dev_guide.rst @@ -4,7 +4,7 @@ Galaxy Developer Guide ********************** -You can host collections and roles on Galaxy to share with the Ansible community. Galaxy content is formated in pre-packaged units of work such as `roles `_, and new in Galaxy 3.2, `collections `_. +You can host collections and roles on Galaxy to share with the Ansible community. Galaxy content is formated in pre-packaged units of work such as :ref:`roles `, and new in Galaxy 3.2, :ref:`collections `. You can create roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. Taking this a step further, you can create collections which provide a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins. .. contents:: diff --git a/docs/docsite/rst/galaxy/user_guide.rst b/docs/docsite/rst/galaxy/user_guide.rst index 8ded40660a6..275fb75ed9e 100644 --- a/docs/docsite/rst/galaxy/user_guide.rst +++ b/docs/docsite/rst/galaxy/user_guide.rst @@ -7,7 +7,7 @@ Galaxy User Guide :dfn:`Ansible Galaxy` refers to the `Galaxy `_ website, a free site for finding, downloading, and sharing community developed roles. -Use Galaxy to jump-start your automation project with great content from the Ansible community. Galaxy provides pre-packaged units of work such as `roles `_, and new in Galaxy 3.2, `collections `_. +Use Galaxy to jump-start your automation project with great content from the Ansible community. Galaxy provides pre-packaged units of work such as :ref:`roles `, and new in Galaxy 3.2, :ref:`collections ` You can find roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. The collection format provides a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins. .. contents:: diff --git a/docs/docsite/rst/scenario_guides/guide_kubernetes.rst b/docs/docsite/rst/scenario_guides/guide_kubernetes.rst index 4e20a05549f..9f24abcbf4f 100644 --- a/docs/docsite/rst/scenario_guides/guide_kubernetes.rst +++ b/docs/docsite/rst/scenario_guides/guide_kubernetes.rst @@ -8,7 +8,7 @@ Requirements To use the modules, you'll need the following: -- Run Ansible from source. For assistance, view `running from source <./intro_installation.html/#running-from-source>`_ +- Run Ansible from source. For assistance, view :ref:`from_source`. - `OpenShift Rest Client `_ installed on the host that will execute the modules diff --git a/docs/docsite/rst/scenario_guides/guide_packet.rst b/docs/docsite/rst/scenario_guides/guide_packet.rst index 74a2df5c9e3..992821a5418 100644 --- a/docs/docsite/rst/scenario_guides/guide_packet.rst +++ b/docs/docsite/rst/scenario_guides/guide_packet.rst @@ -31,7 +31,7 @@ To use the modules and inventory script you'll need a Packet API token. You can If you're not comfortable exporting your API token, you can pass it as a parameter to the modules. -On Packet, devices and reserved IP addresses belong to `projects `_. In order to use the packet_device module, you need to specify the UUID of the project in which you want to create or manage devices. You can find a project's UUID in the Packet portal `here `_ (it's just under the project table) or via one of the available `CLIs `_. +On Packet, devices and reserved IP addresses belong to `projects `_. In order to use the packet_device module, you need to specify the UUID of the project in which you want to create or manage devices. You can find a project's UUID in the Packet portal `here `_ (it's just under the project table) or via one of the available `CLIs `_. If you want to use a new SSH keypair in this tutorial, you can generate it to ``./id_rsa`` and ``./id_rsa.pub`` as: @@ -46,7 +46,7 @@ If you want to use an existing keypair, just copy the private and public key ove Device Creation =============== -The following code block is a simple playbook that creates one `Type 0 `_ server (the 'plan' parameter). You have to supply 'plan' and 'operating_system'. 'location' defaults to 'ewr1' (Parsippany, NJ). You can find all the possible values for the parameters via a `CLI client `_. +The following code block is a simple playbook that creates one `Type 0 `_ server (the 'plan' parameter). You have to supply 'plan' and 'operating_system'. 'location' defaults to 'ewr1' (Parsippany, NJ). You can find all the possible values for the parameters via a `CLI client `_. .. code-block:: yaml diff --git a/docs/docsite/rst/user_guide/modules_support.rst b/docs/docsite/rst/user_guide/modules_support.rst index b3922df781e..75ddd71f193 100644 --- a/docs/docsite/rst/user_guide/modules_support.rst +++ b/docs/docsite/rst/user_guide/modules_support.rst @@ -46,7 +46,7 @@ For development-oriented topics, use the `ansible-devel Google group `_ repo. -NOTE: If you have a Red Hat Ansible Automation product subscription, please follow the standard issue reporting process via the `Red Hat Customer Portal `_. +NOTE: If you have a Red Hat Ansible Automation product subscription, please follow the standard issue reporting process via the `Red Hat Customer Portal `_. Support ======= diff --git a/docs/docsite/rst/user_guide/windows_dsc.rst b/docs/docsite/rst/user_guide/windows_dsc.rst index b8f1b41feeb..10131f25813 100644 --- a/docs/docsite/rst/user_guide/windows_dsc.rst +++ b/docs/docsite/rst/user_guide/windows_dsc.rst @@ -210,7 +210,7 @@ For example, to define a ``[CimInstance]`` value in Ansible: Windows: yes In the above example, the CIM instance is a representation of the class -`MSFT_xWebAuthenticationInformation `_. +`MSFT_xWebAuthenticationInformation `_. This class accepts four boolean variables, ``Anonymous``, ``Basic``, ``Digest``, and ``Windows``. The keys to use in a ``[CimInstance]`` depend on the class it represents. Please read through the documentation of the resource @@ -265,7 +265,7 @@ like this example: Port: 80 IPAddress: '*' -The above example, is an array with two values of the class `MSFT_xWebBindingInformation `_. +The above example, is an array with two values of the class `MSFT_xWebBindingInformation `_. When defining a ``[CimInstance[]]``, be sure to read the resource documentation to find out what keys to use in the definition. diff --git a/docs/templates/config.rst.j2 b/docs/templates/config.rst.j2 index a33ab428de1..44be320d4e3 100644 --- a/docs/templates/config.rst.j2 +++ b/docs/templates/config.rst.j2 @@ -64,7 +64,7 @@ filesystem so the files and directories are readable and writable by the users and groups running Ansible but closed to others. For more details on the correct settings, see: -* for Vagrant, Jeremy Kendall's `blog post `_ covers synced folder permissions. +* for Vagrant, the `Vagrant documentation `_ covers synced folder permissions. * for WSL, the `WSL docs `_ and this `Microsoft blog post `_ cover mount options.