Fixes more rST errors (#39042)

* removes include, avoids duplicate label rST warnings

* reduces literal_block errors on playbooks_filters

* addresses TOC errors

* ref error on modules page

* trying ref for list_of_database_modules

docs/docsite/rst/dev_guide/developing_modules.rst

@@ -108,5 +108,3 @@ The following topics will discuss how to develop and work with modules:
    `irc.freenode.net <http://irc.freenode.net>`_
        #ansible IRC chat channel
 
-
-.. include:: ./developing_module_utilities.rst

docs/docsite/rst/dev_guide/developing_modules_in_groups.rst

@@ -33,7 +33,7 @@ Although it's tempting to get straight into coding, there are a few things to be
 Naming Convention
 `````````````````
 
-As you may have noticed when looking under ``lib/ansible/modules/`` we support up to two directories deep (but no deeper), e.g. `databases/mysql`. This is used to group files on disk as well as group related modules into categories and topics the Module Index, for example: :doc:`../list_of_database_modules`.
+As you may have noticed when looking under ``lib/ansible/modules/`` we support up to two directories deep (but no deeper), e.g. `databases/mysql`. This is used to group files on disk as well as group related modules into categories and topics the Module Index, for example: :ref:`list_of_database_modules`.
 
 The directory name should represent the *product* or *OS* name, not the company name.
 

docs/docsite/rst/index.rst

@@ -66,7 +66,7 @@ Ansible releases a new major release of Ansible approximately every two months.
    :caption: Ansible for Network Automation
 
    network/index
-   network/getting_started
+   network/getting_started/index
 
 .. toctree::
    :maxdepth: 2

docs/docsite/rst/plugins/plugins.rst

@@ -22,8 +22,8 @@ This section covers the various types of plugins that are included with Ansible:
    shell
    strategy
    vars
-   playbooks_filters
-   playbooks_tests
+   ../user_guide/playbooks_filters
+   ../user_guide/playbooks_tests
    ../user_guide/plugin_filtering_config
 
 .. seealso::

docs/docsite/rst/user_guide/intro.rst

@@ -6,13 +6,13 @@ Before we start exploring the main components of Ansible -- playbooks, configura
 .. toctree::
    :maxdepth: 1
 
-   installation_guide/index
+   ../installation_guide/index
    ../dev_guide/overview_architecture
    intro_getting_started
    intro_inventory
    intro_dynamic_inventory
    intro_patterns
    intro_adhoc
-   intro_configuration
+   ../installation_guide/intro_configuration
    intro_bsd
    intro_windows

docs/docsite/rst/user_guide/modules.rst

@@ -7,7 +7,7 @@ Working With Modules
    :maxdepth: 1
 
    modules_intro
-   common_return_values
+   ../reference_appendices/common_return_values
    modules_support
    ../modules/modules_by_category
 

docs/docsite/rst/user_guide/playbooks_filters.rst

@@ -384,74 +384,85 @@ Network CLI filters
 To convert the output of a network device CLI command into structured JSON
 output, use the ``parse_cli`` filter::
 
+.. code-block:: yaml
+
   {{ output | parse_cli('path/to/spec') }}
 
+
 The ``parse_cli`` filter will load the spec file and pass the command output
 through it, returning JSON output. The YAML spec file defines how to parse the CLI output.
 
 The spec file should be valid formatted YAML.  It defines how to parse the CLI
 output and return JSON data.  Below is an example of a valid spec file that
-will parse the output from the ``show vlan`` command.::
+will parse the output from the ``show vlan`` command.
 
-    ---
-    vars:
-      vlan:
-        vlan_id: "{{ item.vlan_id }}"
-        name: "{{ item.name }}"
-        enabled: "{{ item.state != 'act/lshut' }}"
-        state: "{{ item.state }}"
+.. code-block:: yaml
+
+   ---
+   vars:
+     vlan:
+       vlan_id: "{{ item.vlan_id }}"
+       name: "{{ item.name }}"
+       enabled: "{{ item.state != 'act/lshut' }}"
+       state: "{{ item.state }}"
+
+   keys:
+     vlans:
+       value: "{{ vlan }}"
+       items: "^(?P<vlan_id>\\d+)\\s+(?P<name>\\w+)\\s+(?P<state>active|act/lshut|suspended)"
+     state_static:
+       value: present
 
-    keys:
-      vlans:
-        value: "{{ vlan }}"
-        items: "^(?P<vlan_id>\\d+)\\s+(?P<name>\\w+)\\s+(?P<state>active|act/lshut|suspended)"
-      state_static:
-        value: present
 
 The spec file above will return a JSON data structure that is a list of hashes
 with the parsed VLAN information.
 
 The same command could be parsed into a hash by using the key and values
 directives.  Here is an example of how to parse the output into a hash
-value using the same ``show vlan`` command.::
+value using the same ``show vlan`` command.
 
-    ---
-    vars:
-      vlan:
-        key: "{{ item.vlan_id }}"
-        values:
-          vlan_id: "{{ item.vlan_id }}"
-          name: "{{ item.name }}"
-          enabled: "{{ item.state != 'act/lshut' }}"
-          state: "{{ item.state }}"
+.. code-block:: yaml
+
+   ---
+   vars:
+     vlan:
+       key: "{{ item.vlan_id }}"
+       values:
+         vlan_id: "{{ item.vlan_id }}"
+         name: "{{ item.name }}"
+         enabled: "{{ item.state != 'act/lshut' }}"
+         state: "{{ item.state }}"
+
+   keys:
+     vlans:
+       value: "{{ vlan }}"
+       items: "^(?P<vlan_id>\\d+)\\s+(?P<name>\\w+)\\s+(?P<state>active|act/lshut|suspended)"
+     state_static:
+       value: present
 
-    keys:
-      vlans:
-        value: "{{ vlan }}"
-        items: "^(?P<vlan_id>\\d+)\\s+(?P<name>\\w+)\\s+(?P<state>active|act/lshut|suspended)"
-      state_static:
-        value: present
 
 Another common use case for parsing CLI commands is to break a large command
 into blocks that can be parsed.  This can be done using the ``start_block`` and
-``end_block`` directives to break the command into blocks that can be parsed.::
+``end_block`` directives to break the command into blocks that can be parsed.
 
-    ---
-    vars:
-      interface:
-        name: "{{ item[0].match[0] }}"
-        state: "{{ item[1].state }}"
-        mode: "{{ item[2].match[0] }}"
+.. code-block:: yaml
 
-    keys:
-      interfaces:
-        value: "{{ interface }}"
-        start_block: "^Ethernet.*$"
-        end_block: "^$"
-        items:
-          - "^(?P<name>Ethernet\\d\\/\\d*)"
-          - "admin state is (?P<state>.+),"
-          - "Port mode is (.+)"
+   ---
+   vars:
+     interface:
+       name: "{{ item[0].match[0] }}"
+       state: "{{ item[1].state }}"
+       mode: "{{ item[2].match[0] }}"
+
+   keys:
+     interfaces:
+       value: "{{ interface }}"
+       start_block: "^Ethernet.*$"
+       end_block: "^$"
+       items:
+         - "^(?P<name>Ethernet\\d\\/\\d*)"
+         - "admin state is (?P<state>.+),"
+         - "Port mode is (.+)"
 
 
 The example above will parse the output of ``show interface`` into a list of
@@ -482,54 +493,59 @@ The spec file should be valid formatted YAML. It defines how to parse the XML
 output and return JSON data.
 
 Below is an example of a valid spec file that
-will parse the output from the ``show vlan | display xml`` command.::
+will parse the output from the ``show vlan | display xml`` command.
 
-    ---
-    vars:
-      vlan:
-        vlan_id: "{{ item.vlan_id }}"
-        name: "{{ item.name }}"
-        desc: "{{ item.desc }}"
-        enabled: "{{ item.state.get('inactive') != 'inactive' }}"
-        state: "{% if item.state.get('inactive') == 'inactive'%} inactive {% else %} active {% endif %}"
+.. code-block:: yaml
+
+   ---
+   vars:
+     vlan:
+       vlan_id: "{{ item.vlan_id }}"
+       name: "{{ item.name }}"
+       desc: "{{ item.desc }}"
+       enabled: "{{ item.state.get('inactive') != 'inactive' }}"
+       state: "{% if item.state.get('inactive') == 'inactive'%} inactive {% else %} active {% endif %}"
+
+   keys:
+     vlans:
+       value: "{{ vlan }}"
+       top: configuration/vlans/vlan
+       items:
+         vlan_id: vlan-id
+         name: name
+         desc: description
+         state: ".[@inactive='inactive']"
 
-    keys:
-      vlans:
-        value: "{{ vlan }}"
-        top: configuration/vlans/vlan
-        items:
-          vlan_id: vlan-id
-          name: name
-          desc: description
-          state: ".[@inactive='inactive']"
 
 The spec file above will return a JSON data structure that is a list of hashes
 with the parsed VLAN information.
 
 The same command could be parsed into a hash by using the key and values
 directives.  Here is an example of how to parse the output into a hash
-value using the same ``show vlan | display xml`` command.::
+value using the same ``show vlan | display xml`` command.
 
-    ---
-    vars:
-      vlan:
-        key: "{{ item.vlan_id }}"
-        values:
-            vlan_id: "{{ item.vlan_id }}"
-            name: "{{ item.name }}"
-            desc: "{{ item.desc }}"
-            enabled: "{{ item.state.get('inactive') != 'inactive' }}"
-            state: "{% if item.state.get('inactive') == 'inactive'%} inactive {% else %} active {% endif %}"
+.. code-block:: yaml
 
-    keys:
-      vlans:
-        value: "{{ vlan }}"
-        top: configuration/vlans/vlan
-        items:
-          vlan_id: vlan-id
-          name: name
-          desc: description
-          state: ".[@inactive='inactive']"
+   ---
+   vars:
+     vlan:
+       key: "{{ item.vlan_id }}"
+       values:
+           vlan_id: "{{ item.vlan_id }}"
+           name: "{{ item.name }}"
+           desc: "{{ item.desc }}"
+           enabled: "{{ item.state.get('inactive') != 'inactive' }}"
+           state: "{% if item.state.get('inactive') == 'inactive'%} inactive {% else %} active {% endif %}"
+
+   keys:
+     vlans:
+       value: "{{ vlan }}"
+       top: configuration/vlans/vlan
+       items:
+         vlan_id: vlan-id
+         name: name
+         desc: description
+         state: ".[@inactive='inactive']"
 
 
 The value of ``top`` is the XPath relative to the XML root node.