[backport][2.10] Docsbackportapaloosa (#70302)

* Fix broken link in AWS Guide (#70153)

Point to collection rather than ansible/ansible for example.

(cherry picked from commit 0ef75f65d9)

* remove gendered example (#70117)

Changed example to not assume things about names and genders

(cherry picked from commit 5885ed4455)

* docs: Add note about ansible-doc (#70162)

ansible-doc can only parse Python modules, added a note about
this is developer guide; Fixes: #69109

(cherry picked from commit da868d9d60)

* Update config.yml (#70154)

typos & branding
* Update .github/ISSUE_TEMPLATE/config.yml

Co-authored-by: Rick Elrod <rick@elrod.me>
(cherry picked from commit 4b358c6641)

* async_status: Update documentation (#70196)

Fixes: #38164

Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
(cherry picked from commit 40a42de081)

* updates to ansible-maintained collections guidelines (#70178)

(cherry picked from commit 647c6cd289)

Co-authored-by: Jill R <4121322+jillr@users.noreply.github.com>
Co-authored-by: Westley Argentum Hennigh-Palermo <WestleyArgentum@gmail.com>
Co-authored-by: Abhijeet Kasurde <akasurde@redhat.com>
Co-authored-by: John R Barker <john@johnrbarker.com>

.github/ISSUE_TEMPLATE/config.yml

@@ -20,7 +20,7 @@ contact_links:
   about: Please ask and answer usage questions here
 - name: ⚡ Working groups
   url: https://github.com/ansible/community/wiki
-  about: Interedted in improving a specific area? Become a part of a working group!
+  about: Interested in improving a specific area? Become a part of a working group!
 - name: 💼 For Enterprise
   url: https://www.ansible.com/products/engine?utm_medium=github&utm_source=issue_template_chooser
-  about: Red Hat offers supported builds of Ansible Engine
+  about: Red Hat offers support for the Ansible Automation Platform

docs/docsite/rst/community/contributing_maintained_collections.rst

@@ -120,7 +120,7 @@ The following table shows:
     </tr>
     <tr>
       <td><a href="https://galaxy.ansible.com/cisco/asa">cisco.asa</a></td>
-      <td>community.asa</td>
+      <td><a href="https://github.com/ansible-collections/community.asa">community.asa</a></td>
       <td><a href="https://github.com/ansible/community/wiki/Security-Automation">Security</a></td>
       <td>✓</td>
       <td>✓</td>
@@ -164,7 +164,7 @@ The following table shows:
     </tr>
     <tr>
       <td><a href="https://galaxy.ansible.com/ibm/qradar">ibm.qradar</a></td>
-      <td>community.qradar</td>
+      <td><a href="https://github.com/ansible-collections/community.qradar">community.qradar</a></td>
       <td><a href="https://github.com/ansible/community/wiki/Security-Automation">Security</a></td>
       <td>✓</td>
       <td></td>
@@ -197,7 +197,7 @@ The following table shows:
     </tr>
     <tr>
       <td><a href="https://github.com/ansible-collections/splunk.es">splunk.es</a></td>
-      <td>community.es</td>
+      <td><a href="https://github.com/ansible-collections/community.es">community.es</a></td>
       <td><a href="https://github.com/ansible/community/wiki/Security-Automation">Security</a></td>
       <td>✓</td>
       <td></td>
@@ -250,7 +250,7 @@ The following scenarios use the ``arista.eos`` to help explain when to contribut
     * Propose a new module in the ``community.network`` collection (requires network community approval).
     * Place your new module in a collection in your own namespace (no approvals required).
 
-  
+
 Most new content should go into either a related community collection or your own collection first so that is well established in the community before you can propose adding it to the  ``arista`` namespace, where inclusion and maintenance criteria are much higher.
 
 

docs/docsite/rst/dev_guide/developing_locally.rst

@@ -45,6 +45,10 @@ To confirm that ``my_custom_module`` is available:
 
 * type ``ansible-doc -t module my_custom_module``. You should see the documentation for that module.
 
+.. note::
+
+	Currently, ``ansible-doc`` command can only parse Python modules for the module documentation. If you have module written in a different programming language other than Python, please write a documentation in Python file adjacent to module file.
+
 To use a local module only in certain playbooks:
 
 * store it in a sub-directory called ``library`` in the directory that contains the playbook(s)

docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst

@@ -638,7 +638,7 @@ available during the test run. Second putting the test in a test group causing i
 continuous integration build.
 
 Tests for new modules should be added to the same group as existing AWS tests. In general just copy
-an existing aliases file such as the `aws_s3 tests aliases file <https://github.com/ansible/ansible/blob/devel/test/integration/targets/aws_s3/aliases>`_.
+an existing aliases file such as the `aws_s3 tests aliases file <https://github.com/ansible-collections/amazon.aws/blob/master/tests/integration/targets/aws_s3/aliases>`_.
 
 AWS Credentials for Integration Tests
 -------------------------------------

docs/docsite/rst/network/dev_guide/developing_resource_modules_network.rst

@@ -511,9 +511,9 @@ For platforms that support ``connection: local`` *and* ``connection: network_cli
 * Name the :file:`targets/` directories after the module name.
 * The :file:`main.yaml` file should just reference the transport.
 
-The following example walks through the integration tests for the ``vyos.vyos.vyos_banner`` module in the `vyos.vyos <https://github.com/ansible-collections/vyos.vyos/tree/master/tests/integration>`_ collection:
+The following example walks through the integration tests for the ``vyos.vyos.vyos_l3_interfaces`` module in the `vyos.vyos <https://github.com/ansible-collections/vyos.vyos/tree/master/tests/integration>`_ collection:
 
-``test/integration/targets/vyos_banner/tasks/main.yaml``
+``test/integration/targets/vyos_l3_interfaces/tasks/main.yaml``
 
 .. code-block:: yaml
 
@@ -522,7 +522,7 @@ The following example walks through the integration tests for the ``vyos.vyos.vy
      tags:
        - cli
 
-``test/integration/targets/vyos_banner/tasks/cli.yaml``
+``test/integration/targets/vyos_l3_interfaces/tasks/cli.yaml``
 
 .. code-block:: yaml
 
@@ -549,46 +549,71 @@ The following example walks through the integration tests for the ``vyos.vyos.vy
      loop_control:
        loop_var: test_case_to_run
 
-``test/integration/targets/vyos_banner/tests/cli/basic-no-login.yaml``
+``test/integration/targets/vyos_l3_interfaces/tests/cli/overridden.yaml``
 
 .. code-block:: yaml
 
-   ---
-   - debug:
-       msg: "cli/basic-no-login.yaml on connection={{ ansible_connection }}"
-
-   - name: Setup
-     vyos_banner:
-       banner: pre-login
-       text: |
-         Junk pre-login banner
-         over multiple lines
-       state: present
-
-   - name: remove pre-login
-     vyos_banner:
-       banner: pre-login
-       state: absent
+  ---
+  - debug:
+   msg: START vyos_l3_interfaces merged integration tests on connection={{ ansible_connection
+     }}
+
+  - include_tasks: _remove_config.yaml
+
+  - block:
+
+   - include_tasks: _populate.yaml
+
+   - name: Overrides all device configuration with provided configuration
      register: result
+     vyos.vyos.vyos_l3_interfaces: &id001
+       config:
+
+         - name: eth0
+           ipv4:
+
+             - address: dhcp
 
-   - debug:
-       msg: "{{ result }}"
+         - name: eth1
+           ipv4:
 
-   - assert:
+             - address: 192.0.2.15/24
+       state: overridden
+
+   - name: Assert that before dicts were correctly generated
+     assert:
+       that:
+         - "{{ populate | symmetric_difference(result['before']) |length == 0 }}"
+
+   - name: Assert that correct commands were generated
+     assert:
+       that:
+         - "{{ overridden['commands'] | symmetric_difference(result['commands'])\
+           \ |length == 0 }}"
+
+   - name: Assert that after dicts were correctly generated
+     assert:
        that:
-         - "result.changed == true"
-         - "'delete system login banner pre-login' in result.commands"
+         - "{{ overridden['after'] | symmetric_difference(result['after']) |length\
+           \ == 0 }}"
 
-   - name: remove pre-login (idempotent)
-     vyos_banner:
-       banner: pre-login
-       state: absent
+   - name: Overrides all device configuration with provided configurations (IDEMPOTENT)
      register: result
+     vyos.vyos.vyos_l3_interfaces: *id001
+
+   - name: Assert that the previous task was idempotent
+     assert:
+       that:
+         - result['changed'] == false
 
-   - assert:
+   - name: Assert that before dicts were correctly generated
+     assert:
        that:
-         - "result.changed == false"
-         - "result.commands | length == 0"
+         - "{{ overridden['after'] | symmetric_difference(result['before']) |length\
+           \ == 0 }}"
+  always:
+
+   - include_tasks: _remove_config.yaml
 
 
 Detecting test resources at runtime
@@ -659,14 +684,14 @@ To run integration tests for a specific module:
 
 .. code-block:: bash
 
-  ansible-test network-integration --inventory  /path/to-collection-module/test/integration/inventory.networking vyos_vlan
+  ansible-test network-integration --inventory  /path/to-collection-module/test/integration/inventory.networking vyos_l3_interfaces
 
 To run a single test case on a specific module:
 
 .. code-block:: bash
 
-   # Only run vyos_vlan/tests/cli/basic.yaml
-   ansible-test network-integration --inventory  /path/to-collection-module/test/integration/inventory.networking vyos_vlan --testcase basic
+   # Only run vyos_l3_interfaces/tests/cli/gathered.yaml
+   ansible-test network-integration --inventory  /path/to-collection-module/test/integration/inventory.networking vyos_l3_interfaces --testcase gathered
 
 To run integration tests for a specific transport:
 

docs/docsite/rst/user_guide/playbooks_async.rst

@@ -102,7 +102,8 @@ If you need a synchronization point with an async task, you can register it to o
           jid: "{{ yum_sleeper.ansible_job_id }}"
         register: job_result
         until: job_result.finished
-        retries: 30
+        retries: 100
+        delay: 10
 
 .. note::
    If the value of ``async:`` is not high enough, this will cause the

docs/docsite/rst/user_guide/playbooks_filters.rst

@@ -76,7 +76,7 @@ Defining different values for true/false/null
 
 You can create a test, then define one value to use when the test returns true and another when the test returns false (new in version 1.9)::
 
-    {{ (name == "John") | ternary('Mr','Ms') }}
+    {{ (status == "needs_restart") | ternary('restart', 'continue') }}
 
 In addition, you can define a one value to use on true, one value on false and a third value on null (new in version 2.8)::
 

lib/ansible/modules/async_status.py

@@ -54,7 +54,8 @@ EXAMPLES = r'''
     jid: '{{ yum_sleeper.ansible_job_id }}'
   register: job_result
   until: job_result.finished
-  retries: 30
+  retries: 100
+  delay: 10
 '''
 
 RETURN = r'''