Backportapalooza 10 27 (#79247)

* managed node requirement amend (#79189)

(cherry picked from commit 757efa4)

* documentation fix for file module 78988 (#79182)

(cherry picked from commit 465480f)

* Added link to the Ansible meetup page (#79207)

(cherry picked from commit f3f7d44)

* add link to fest videos (#79196)

(cherry picked from commit 060f114)

* Docs: Typos and edits in collections integration (#79228)

(cherry picked from commit 74f55db)

* fix url for fest VoD banner (#79229)

(cherry picked from commit 656d01d)

* Docs: Typos and edits in collections reviews (#79217)

(cherry picked from commit fa8dc6b)

* plugins/lookup/pipe: docs typo fixes (#79222)

(cherry picked from commit 0bacea7)

* collection roles dont support plugins (#79243)

(cherry picked from commit 6ee089b)

Co-authored-by: prasadpatil49 <51715670+prasadpatil49@users.noreply.github.com>
Co-authored-by: VICTORIA JOHNSON <110999245+DrVickie8@users.noreply.github.com>
Co-authored-by: Goodness Chris-Ugari <goodnesschrisugari@yahoo.com>
Co-authored-by: Kenyon Ralph <kenyon@kenyonralph.com>
Co-authored-by: Brian Coca <bcoca@users.noreply.github.com>

docs/docsite/.templates/banner.html

@@ -15,19 +15,16 @@
     }
     var banner = '';
       var extra_banner = '';
-    /*use extra_banner for when marketing wants something extra, like a survey or AnsibleFest notice *
+    /*use extra_banner for when marketing wants something extra, like a survey or AnsibleFest notice */
     var extra_banner =
       '<div id="latest_extra_banner_id" class="admonition important">' +
       '<br>' +
       '<p>' +
-        'Immerse yourself in the automation experience October 18-19 in Chicago. ' +
-      '<p>' +
-        'Join us for AnsibleFest 2022. ' +
-      '<pr>' +
-        '<a href="https://www.ansible.com/ansiblefest?intcmp=7013a000002tuDxAAI">Register now!</a> ' +
+        'Continue building on your automation knowledge, visit the <a href="https://events.experiences.redhat.com/widget/redhat/rhaf22/SessionCatalog2022">AnsibleFest content hub!</a>  ' +
+
       '</p>' +
       '<br>' +
-      '</div>'; */
+      '</div>'; 
     // Create a banner if we're not on the official docs site
     if (location.host == "docs.testing.ansible.com") {
       document.write('<div id="testing_banner_id" class="admonition important">' +

docs/docsite/rst/collections_guide/collections_using_playbooks.rst

@@ -112,6 +112,8 @@ A few recommendations when creating such playbooks, ``hosts:`` should be generic
 This will have an implied entry in the ``collections:`` keyword of ``my_namespace.my_collection`` just as with roles.
 
 .. note::
-    Playbook names, like other collection resources, have a restricted set of valid characters.
-    Names can contain only lowercase alphanumeric characters, plus _ and must start with an alpha character. The dash ``-`` character is not valid for playbook names in collections.
-    Playbooks whose names contain invalid characters are not addressable: this is a limitation of the Python importer that is used to load collection resources.
+    * Playbook names, like other collection resources, have a restricted set of valid characters.
+      Names can contain only lowercase alphanumeric characters, plus _ and must start with an alpha character. The dash ``-`` character is not valid for playbook names in collections.
+      Playbooks whose names contain invalid characters are not addressable: this is a limitation of the Python importer that is used to load collection resources.
+
+    * Playbooks in collections do not support 'adjacent' plugins, all plugins must be in the collection specific directories.

docs/docsite/rst/community/collection_contributors/collection_integration_add.rst

@@ -5,7 +5,7 @@ Creating new integration tests
 
 This section covers the following cases:
 
-- There are no integration tests for a collection / group of modules in a collection at all.
+- There are no integration tests for a collection or group of modules in a collection at all.
 - You are adding a new module and you want to include integration tests.
 - You want to add integration tests for a module that already exists without integration tests.
 
@@ -92,7 +92,7 @@ Add the following to ``tests/integration/targets/abstract_service_info/tasks/mai
   - name: Fetch info from abstract service
     abstract_service_info:
       host: 127.0.0.1  # We assume the service accepts local connection by default
-      port: 1234       # We assume that the service is listening this port by default
+      port: 1234       # We assume that the service is listening to this port by default
     register: result   # This variable will contain the returned JSON including the server version
 
   - name: Test the output
@@ -104,7 +104,7 @@ Add the following to ``tests/integration/targets/abstract_service_info/tasks/mai
 
 If there are any issues with connectivity (for example, the service is not accepting connections) or with the code, the play will fail.
 
-Examine the output to see at which step the failure occurred. Investigate the reason, fix, and run again. Repeat the cycle until the test passes.
+Examine the output to see at which step the failure occurred. Investigate the reason, fix it, and run again. Repeat the cycle until the test passes.
 
 8. If the test succeeds, write more tests. Refer to the :ref:`Recommendations on coverage<collection_integration_recommendations>` section for details.
 
@@ -201,7 +201,7 @@ That is enough for our very basic example.
 
   mkdir -p tests/integration/targets/postgresql_info/tasks tests/integration/targets/postgresql_info/meta
 
-11. To make the ``setup_postgresql_db`` target running before the ``postgresql_info`` target as a dependency, create the ``tests/integration/targets/postgresql_info/meta/main.yml`` file and add the following code to it:
+11. To make the ``setup_postgresql_db`` target run before the ``postgresql_info`` target as a dependency, create the ``tests/integration/targets/postgresql_info/meta/main.yml`` file and add the following code to it:
 
 .. code-block:: yaml
 
@@ -247,4 +247,4 @@ The tests should pass. If we look at the output, we should see something like th
     "msg": "All assertions passed"
   }
 
-If your tests fail when you are working on your project, examine the output to see at which step the failure occurred. Investigate the reason, fix, and run again. Repeat the cycle until the test passes. If the test succeeds, write more tests. Refer to the :ref:`Recommendations on coverage<collection_integration_recommendations>` section for details.
+If your tests fail when you are working on your project, examine the output to see at which step the failure occurred. Investigate the reason, fix it, and run again. Repeat the cycle until the test passes. If the test succeeds, write more tests. Refer to the :ref:`Recommendations on coverage<collection_integration_recommendations>` section for details.

docs/docsite/rst/community/collection_contributors/collection_integration_running.rst

@@ -3,7 +3,7 @@
 Running integration tests
 ============================
 
-In the following examples, we will use ``Docker`` to run integration tests locally. Ensure you have :ref:`collection_prepare_environment` first.
+In the following examples, we will use ``Docker`` to run integration tests locally. Ensure you :ref:`collection_prepare_environment` first.
 
 We assume that you are in the ``~/ansible_collections/NAMESPACE/COLLECTION`` directory.
 
@@ -25,7 +25,7 @@ In the examples above, the ``fedora34`` test image will be automatically downloa
 
 See the :ref:`list of supported container images <test_container_images>`.
 
-In some cases, for example, for platform independent tests, the ``default`` test image is required. Use the ``--docker default`` or just ``--docker`` option without specifying a distribution in this case.
+In some cases, for example, for platform-independent tests, the ``default`` test image is required. Use the ``--docker default`` or just ``--docker`` option without specifying a distribution in this case.
 
 .. note::
 

docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst

@@ -6,7 +6,7 @@ Adding to an existing integration test
 The test tasks are stored in the ``tests/integration/targets/<target_name>/tasks`` directory.
 
 The ``main.yml`` file holds test tasks and includes other test files.
-Look for a suitable test file to integrate your tests or create and include / import a separate test file.
+Look for a suitable test file to integrate your tests or create and include or import a separate test file.
 You can use one of the existing test files as a draft.
 
 When fixing a bug
@@ -15,9 +15,9 @@ When fixing a bug
 When fixing a bug:
 
 1. :ref:`Determine if integration tests for the module exist<collection_integration_prepare>`. If they do not, see :ref:`collection_creating_integration_tests` section.
-2. Add a task which reproduces the bug to an appropriate file within the ``tests/integration/targets/<target_name>/tasks`` directory.
+2. Add a task that reproduces the bug to an appropriate file within the ``tests/integration/targets/<target_name>/tasks`` directory.
 3. :ref:`Run the tests<collection_run_integration_tests>`. The newly added task should fail.
-4. If they do not fail, re-check if your environment / test task satisfies the conditions described in the ``Steps to Reproduce`` section of the issue.
+4. If they do not fail, re-check if your environment or test task satisfies the conditions described in the ``Steps to Reproduce`` section of the issue.
 5. If you reproduce the bug and tests fail, change the code.
 6. :ref:`Run the tests<collection_run_integration_tests>` again.
 7. If they fail, repeat steps 5-6 until the tests pass.
@@ -74,7 +74,7 @@ When adding a new feature
 
   The process described in this section also applies when you want to add integration tests to a feature that already exists, but is missing integration tests.
 
-If you have not already implemented the new feature, you can start with writing the integration tests for it. Of course they will not work as the code does not yet exist, but it can help you improve your implementation design before you start writing any code.
+If you have not already implemented the new feature, you can start by writing the integration tests for it. They will not work as the code does not yet exist, but they can help you improve your implementation design before you start writing any code.
 
 When adding new features, the process of adding tests consists of the following steps:
 

docs/docsite/rst/community/collection_contributors/collection_reviewing.rst

@@ -10,20 +10,20 @@ Reviewing bug reports
 
 When users report bugs, verify the behavior reported. Remember always to be kind with your feedback.
 
-*  Did the user made a mistake in the code they put in the Steps to reproduce issue's section? We often see user errors reported as bugs.
+*  Did the user make a mistake in the code they put in the Steps to Reproduce issue section? We often see user errors reported as bugs.
 *  Did the user assume an unexpected behavior? Ensure that the related documentation is clear. If not, the issue is useful to help us improve documentation.
 *  Is there a minimal reproducer? If not, ask the reporter to reduce the complexity to help pinpoint the issue.
-*  Is the issue a consequence of wrong-configured environment?
-*  If it seems to be real bug, does the behaviour still exist in the most recent release or the development branch?
+*  Is the issue a consequence of a misconfigured environment?
+*  If it seems to be a real bug, does the behaviour still exist in the most recent release or the development branch?
 *  Reproduce the bug, or if you do not have a suitable infrastructure, ask other contributors to reproduce the bug.
 
 
 Reviewing suggested changes
 ---------------------------
 
-When reviewing PRs, verify the suggested changes first. Do not:
+When reviewing PRs, verify that the suggested changes do not:
 
-*  Unnecessarily break backwards compatibility.
+*  Unnecessarily break backward compatibility.
 *  Bring more harm than value.
 *  Introduce non-idempotent solutions.
 *  Duplicate already existing features (inside or outside the collection).
@@ -32,7 +32,7 @@ When reviewing PRs, verify the suggested changes first. Do not:
 
 Other standards to check for in a PR include:
 
-*  A pull request MUST NOT contain a mix of bugfixes and new features that are not tightly related. If yes, ask the author to split the pull request into separate PRs.
+*  A pull request MUST NOT contain a mix of bug fixes and new features that are not tightly related. If yes, ask the author to split the pull request into separate PRs.
 *  If the pull request is not a documentation fix, it must include a :ref:`changelog fragment <collection_changelog_fragments>`. Check the format carefully as follows:
 
   * New modules and plugins (that are not jinja2 filter and test plugins) do not need changelog fragments.
@@ -45,7 +45,7 @@ Other standards to check for in a PR include:
 *  If a new plugin is added, it is one of the `allowed plugin types <https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#modules-plugins>`_.
 *  Documentation, examples, and return sections use FQCNs for the ``M(..)`` :ref:`format macros <module_documents_linking>` when referring to modules.
 *  Modules and plugins from ansible-core use ``ansible.builtin.`` as an FQCN prefix when mentioned.
-*  When a new option, module, plugin, or return value is added, the corresponding documentation or return sections use ``version_added:`` containing the *collection* version which they will be first released in.
+*  When a new option, module, plugin, or return value is added, the corresponding documentation or return sections use ``version_added:`` containing the *collection* version in which they will be first released.
 
   * This  is typically the next minor release, sometimes the next major release. For example: if 2.7.5 is the current release, the next minor release will be 2.8.0, and the next major release will be 3.0.0).
 
@@ -70,5 +70,5 @@ Review for merge commits and breaking changes
 ---------------------------------------------
 
 *  The pull request does not contain merge commits. See the GitHub warnings at the bottom of the pull request. If merge commits are present, ask the author to rebase the pull request branch.
-*  If the pull request contains breaking changes, ask the author and the collection maintainers if it really is needed, and there is a way not to introduce breaking changes. If breaking changes are present, they MUST only appear in the next major release and MUST NOT appear in a minor or patch release. The only exception is breaking changes caused by security fixes that are absolutely necessary to fix the security issue.
+*  If the pull request contains breaking changes, ask the author and the collection maintainers if it really is needed, and if there is a way not to introduce breaking changes. If breaking changes are present, they MUST only appear in the next major release and MUST NOT appear in a minor or patch release. The only exception is breaking changes caused by security fixes that are absolutely necessary to fix the security issue.
 

docs/docsite/rst/community/communication.rst

@@ -23,7 +23,7 @@ Your first post to the mailing list will be moderated (to reduce spam), so pleas
 * `Ansible AWX List <https://groups.google.com/forum/#!forum/awx-project>`_ is for `Ansible AWX <https://github.com/ansible/awx>`_
 * `Ansible Development List <https://groups.google.com/forum/#!forum/ansible-devel>`_ is for questions about developing Ansible modules (mostly in Python), fixing bugs in the Ansible core code, asking about prospective feature design, or discussions about extending Ansible or features in progress.
 * `Ansible Lockdown List <https://groups.google.com/forum/#!forum/ansible-lockdown>`_ is for all things related to Ansible Lockdown projects, including DISA STIG automation and CIS Benchmarks.
-* `Ansible Outreach List <https://groups.google.com/forum/#!forum/ansible-outreach>`_ help with promoting Ansible and `Ansible Meetups <https://ansible.meetup.com/>`_
+* `Ansible Outreach List <https://groups.google.com/forum/#!forum/ansible-outreach>`_ help with promoting Ansible and `Ansible Meetups <https://www.meetup.com/topics/ansible/>`_
 * `Ansible Project List <https://groups.google.com/forum/#!forum/ansible-project>`_ is for sharing Ansible tips, answering questions about playbooks and roles, and general user discussion.
 * `Molecule Discussions <https://github.com/ansible-community/molecule/discussions>`_ is designed to aid with the development and testing of Ansible roles with Molecule.