Backportapalooza 03 02 (#80127)

* Add Steampunk Spotter to Other tools list (#80006)

(cherry picked from commit 122de95d8533a8ad34143fe81712a01349c0fc72)

* Clarify combine filter examples (#80078)

(cherry picked from commit 39fd899d83cfcbc6aa313512d2a7f61ac97cfa8a)

* Add Ansible community 7.3.0 porting guide (#80106)

(cherry picked from commit dbcaab1012ab50ea83148155a92c9ca5368ea372)

* Clarify when plugin settings are being populated (#79710)

(cherry picked from commit 998b5c1a06456ae17913d04b47739cf84dd4ae88)

* Update playbooks_tests.rst (#79788)

(cherry picked from commit ed879954f99db8e1a9657efd341f141acab7bf5d)

* consistent booleans for page text and code blocks (#80036)

* consistent booleans for page text and code blocks

* Update check_mode from n to false

(cherry picked from commit 940fdf5dba268c65859d5c55ab554f735467474e)

* Update collection_integration_updating.rst (#80037)

(cherry picked from commit ce5471fc9f0d2709ba4019df0ed586232dc85ce7)

* package_facts requires python-rpm on SUSE systems in ansible 2.12.1 (#80041)

(cherry picked from commit 43aa47c2afb8292fa8ad257353dc3500dda347b9)

* fix: jinja complex type transforms doesn't work as documented (#80067)

jinja complex type transforms: dict(somelist| slice(2)) doesn't work as documented. Changed the example to use zip_longest

(cherry picked from commit 5ad77fc7bb529d9733a17c1ef5d24a84b98f50d3)

* Docs: Clarify note on tags (#80079)

The current wording could be read as "tasks that are tagged *both* configuration and packages" while in fact it is "tasks that are tagged *either* configuration *or* packages"

(cherry picked from commit 563833d124dfe421be019e567f3ac0bbcb23f853)

* Fix typo docs in playbooks_tags.rst (#80117)

(cherry picked from commit c8f740cfee04db8b7078de4613f7c682bc895d59)

* Encourage true/false for module documentation (#80060)

Co-authored-by: Felix Fontein <felix@fontein.de>
(cherry picked from commit 02c49ffe60a232e2f0b16cc973a909a6ad2ae263)

* fix link for development guidelines (#80055)

(cherry picked from commit 012393e2cdb351132d089ce2588a478ac4546b97)

* improve password lookup syntax in examples (#80092)

(cherry picked from commit 809727a7c76c8f20814fecf0e4295f8814bd8984)

* Fixing typos (#80045)

(cherry picked from commit 841b71c94fff27a10377e56547de7f56e08185ef)

* clarify  playbook tests (#80073)

(cherry picked from commit 0521184337d5c4f37c16f2493cc35fdac52d88cf)

* Update playbooks_conditionals.rst (#80062)

"changed" was missing from the docs

(cherry picked from commit cc8e6d06d00ee1655d89e97d8a447b46abf3ae25)

---------

Co-authored-by: Anže Luzar <aluzarwork@gmail.com>
Co-authored-by: Klaus Frank <agowa338@users.noreply.github.com>
Co-authored-by: Anwesha Das <anwesha@das.community>
Co-authored-by: nkakouros <tterranigma@gmail.com>
Co-authored-by: Gijikiki <61326640+Gijikiki@users.noreply.github.com>
Co-authored-by: Aastha Varma <aastha.code@gmail.com>
Co-authored-by: Player256 <92082372+Player256@users.noreply.github.com>
Co-authored-by: Desmond Obisi <51109125+DesmondSanctity@users.noreply.github.com>
Co-authored-by: Raphael Michel <mail@raphaelmichel.de>
Co-authored-by: Nicolas P <0kyn.dev@gmail.com>
Co-authored-by: Kristian Heljas <11139388+kristianheljas@users.noreply.github.com>
Co-authored-by: Akira Yokochi <akira6592@gmail.com>
Co-authored-by: Andreas Deininger <andreas@deininger.net>
Co-authored-by: Keeper-of-the-Keys <es.rosenberg+github@gmail.com>

18 files changed, 91 insertions, 40 deletions

diff --git a/docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst b/docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst
index 46d18c06ef..b519c4d4d1 100644
--- a/docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst
+++ b/docs/docsite/rst/community/collection_contributors/collection_integration_updating.rst
@@ -106,7 +106,7 @@ We will add the following code to the file.
 .. code-block:: yaml
 
   # https://github.com/ansible-collections/community.postgresql/issues/NUM
-  # We should also run the same tasks with check_mode: yes. We omit it here for simplicity.
+  # We should also run the same tasks with check_mode: true. We omit it here for simplicity.
   - name: Test for new_option, create new user WITHOUT the attribute
     community.postgresql.postgresql_user:
       name: test_user      
@@ -149,7 +149,7 @@ We will add the following code to the file.
 
 Then we :ref:`run the tests<collection_run_integration_tests>` with ``postgresql_user`` passed as a test target.
 
-In reality, we would alternate the tasks above with the same tasks run with the ``check_mode: yes`` option to be sure our option works as expected in check-mode as well. See :ref:`Recommendations on coverage<collection_integration_recommendations>` for details.
+In reality, we would alternate the tasks above with the same tasks run with the ``check_mode: true`` option to be sure our option works as expected in check-mode as well. See :ref:`Recommendations on coverage<collection_integration_recommendations>` for details.
 
 If we expect a task to fail, we use the ``ignore_errors: true`` option and check that the task actually failed and returned the message we expect:
 
diff --git a/docs/docsite/rst/community/contributing_maintained_collections.rst b/docs/docsite/rst/community/contributing_maintained_collections.rst
index b0441912b3..f7c0d1d916 100644
--- a/docs/docsite/rst/community/contributing_maintained_collections.rst
+++ b/docs/docsite/rst/community/contributing_maintained_collections.rst
@@ -72,7 +72,7 @@ The following table shows:
       <td>✓</td>
       <td>Zuul</td>
       <td>✓</td>
-      <td><a href="https://docs.ansible.com/ansible/devel/dev_guide/platforms/aws_guidelines.html">AWS guide</a></td>
+      <td><a href="https://docs.ansible.com/ansible/devel/collections/amazon/aws/docsite/dev_guidelines.html">AWS guide</a></td>
     </tr>
     <tr>
       <td><a href="https://galaxy.ansible.com/ansible/netcommon">ansible.netcommon***</a></td>
@@ -247,7 +247,7 @@ The following table shows:
       <td>✓</td>
       <td>Zuul</td>
       <td>✓</td>
-      <td><a href="https://docs.ansible.com/ansible/devel/dev_guide/platforms/vmware_rest_guidelines.html">VMware REST guide</a></td>
+      <td><a href="https://docs.ansible.com/ansible/devel/collections/vmware/vmware_rest/docsite/dev_guide.html">VMware REST guide</a></td>
     </tr>
 
   </table>
diff --git a/docs/docsite/rst/community/other_tools_and_programs.rst b/docs/docsite/rst/community/other_tools_and_programs.rst
index 954d6218ab..40627912f9 100644
--- a/docs/docsite/rst/community/other_tools_and_programs.rst
+++ b/docs/docsite/rst/community/other_tools_and_programs.rst
@@ -120,5 +120,6 @@ Other tools
 - `Mitogen for Ansible <https://mitogen.networkgenomics.com/ansible_detailed.html>`_ - uses the `Mitogen <https://github.com/dw/mitogen/>`_ library to execute Ansible playbooks in a more efficient way (decreases the execution time).
 - `nanvault <https://github.com/marcobellaccini/nanvault>`_ - a standalone tool to encrypt and decrypt files in the Ansible Vault format, featuring UNIX-style composability.
 - `OpsTools-ansible <https://github.com/centos-opstools/opstools-ansible>`_ - uses Ansible to configure an environment that provides the support of `OpsTools <https://wiki.centos.org/SpecialInterestGroup/OpsTools>`_, namely centralized logging and analysis, availability monitoring, and performance monitoring.
+- `Steampunk Spotter <https://pypi.org/project/steampunk-spotter/>`_ - provides an Assisted Automation Writing tool that analyzes and offers recommendations for your Ansible Playbooks.
 - `TD4A <https://github.com/cidrblock/td4a>`_ - a template designer for automation. TD4A is a visual design aid for building and testing jinja2 templates. It will combine data in yaml format with a jinja2 template and render the output.
 - `PHP-Ansible <https://github.com/maschmann/php-ansible>`_ - an object oriented Ansible wrapper for PHP.
diff --git a/docs/docsite/rst/dev_guide/developing_modules_documenting.rst b/docs/docsite/rst/dev_guide/developing_modules_documenting.rst
index f459e43326..e7b5c2d5fb 100644
--- a/docs/docsite/rst/dev_guide/developing_modules_documenting.rst
+++ b/docs/docsite/rst/dev_guide/developing_modules_documenting.rst
@@ -162,8 +162,8 @@ All fields in the ``DOCUMENTATION`` block are lower-case. All fields are require
     * If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing).
     * Ensure that the default value in the docs matches the default value in the code.
     * The default field must not be listed as part of the description, unless it requires additional information or conditions.
-    * If the option is a boolean value, you can use any of the boolean values recognized by Ansible:
-      (such as true/false or yes/no).  Choose the one that reads better in the context of the option.
+    * If the option is a boolean value, you can use any of the boolean values recognized by Ansible
+      (such as ``true``/``false`` or ``yes``/``no``).  Document booleans as ``true``/``false`` for consistency and compatibility with ansible-lint.
 
   :choices:
 
diff --git a/docs/docsite/rst/dev_guide/developing_plugins.rst b/docs/docsite/rst/dev_guide/developing_plugins.rst
index 341e4fc86e..25662f018b 100644
--- a/docs/docsite/rst/dev_guide/developing_plugins.rst
+++ b/docs/docsite/rst/dev_guide/developing_plugins.rst
@@ -75,7 +75,17 @@ To define configurable options for your plugin, describe them in the ``DOCUMENTA
         type: boolean/float/integer/list/none/path/pathlist/pathspec/string/tmppath
         version_added: X.x
 
-To access the configuration settings in your plugin, use ``self.get_option(<option_name>)``. For the plugin types (such as 'become', 'cache', 'callback', 'cliconf', 'connection', 'httpapi', 'inventory', 'lookup', 'netconf', 'shell', and 'vars') that support embedded documentation, the controller pre-populates the settings. If you need to populate settings explicitly, use a ``self.set_options()`` call.
+To access the configuration settings in your plugin, use ``self.get_option(<option_name>)``. 
+Some plugin types hande this differently:
+
+* Become, callback, connection and shell plugins are guaranteed to have the engine call ``set_options()``. 
+* Lookup plugins always require you to handle it in the ``run()`` method.
+* Inventory plugins are done automatically if you use the ``base _read_config_file()`` method. If not, you must use ``self.get_option(<option_name>)``.
+* Cache plugins do it on load.
+* Cliconf, httpapi and netconf plugins indirectly piggy back on connection plugins.
+* Vars plugin settings are populated when first accessed (using the ``self.get_option()`` or ``self.get_options()`` method.
+
+If you need to populate settings explicitly, use a ``self.set_options()`` call.
 
 Configuration sources follow the precedence rules for values in Ansible. When there are multiple values from the same category, the value defined last takes precedence. For example, in the above configuration block, if both ``name_of_ansible_var`` and ``name_of_second_var`` are defined, the value of the ``option_name`` option will be the value of ``name_of_second_var``. Refer to :ref:`general_precedence_rules` for further information.
 
diff --git a/docs/docsite/rst/playbook_guide/complex_data_manipulation.rst b/docs/docsite/rst/playbook_guide/complex_data_manipulation.rst
index 11ed3c388e..e7d23b336f 100644
--- a/docs/docsite/rst/playbook_guide/complex_data_manipulation.rst
+++ b/docs/docsite/rst/playbook_guide/complex_data_manipulation.rst
@@ -230,7 +230,7 @@ These example produces ``{"a": "b", "c": "d"}``
 
   vars:
       single_list: [ 'a', 'b', 'c', 'd' ]
-      mydict: "{{ dict(single_list | slice(2)) }}"
+      mydict: "{{ dict(single_list[::2] | zip_longest(single_list[1::2])) }}"
 
 
 .. code-block:: YAML+Jinja
@@ -240,7 +240,7 @@ These example produces ``{"a": "b", "c": "d"}``
       list_of_pairs: [ ['a', 'b'], ['c', 'd'] ]
       mydict: "{{ dict(list_of_pairs) }}"
 
-Both end up being the same thing, with ``slice(2)`` transforming ``single_list`` to a ``list_of_pairs`` generator.
+Both end up being the same thing, with ``zip_longest`` transforming ``single_list`` to a ``list_of_pairs`` generator.
 
 
 
diff --git a/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst b/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst
index 4b21f7cf92..6b8c827731 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst
@@ -27,8 +27,8 @@ Enforcing or preventing check mode on tasks
 
 If you want certain tasks to run in check mode always, or never, regardless of whether you run the playbook with or without ``--check``, you can add the ``check_mode`` option to those tasks:
 
-  - To force a task to run in check mode, even when the playbook is called without ``--check``, set ``check_mode: yes``.
-  - To force a task to run in normal mode and make changes to the system, even when the playbook is called with ``--check``, set ``check_mode: no``.
+  - To force a task to run in check mode, even when the playbook is called without ``--check``, set ``check_mode: true``.
+  - To force a task to run in normal mode and make changes to the system, even when the playbook is called with ``--check``, set ``check_mode: false``.
 
 For example:
 
@@ -47,9 +47,9 @@ For example:
       check_mode: true
       register: changes_to_important_config
 
-Running single tasks with ``check_mode: yes`` can be useful for testing Ansible modules, either to test the module itself or to test the conditions under which a module would make changes. You can register variables (see :ref:`playbooks_conditionals`) on these tasks for even more detail on the potential changes.
+Running single tasks with ``check_mode: true`` can be useful for testing Ansible modules, either to test the module itself or to test the conditions under which a module would make changes. You can register variables (see :ref:`playbooks_conditionals`) on these tasks for even more detail on the potential changes.
 
-.. note:: Prior to version 2.2 only the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``.
+.. note:: Prior to version 2.2 only the equivalent of ``check_mode: false`` existed. The notation for that was ``always_run: yes``.
 
 Skipping tasks or ignoring errors in check mode
 -----------------------------------------------
diff --git a/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst b/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst
index f920fd74b4..e1bf42d5cb 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst
@@ -175,6 +175,10 @@ Ansible always registers something in a registered variable for every host, even
         ansible.builtin.command: /bin/still/something_else
         when: result is skipped
 
+      - name: Run only if the task that registered the "result" variable changed something.
+        ansible.builtin.command: /bin/still/something_else
+        when: result is changed
+        
 .. note:: Older versions of Ansible used ``success`` and ``fail``, but ``succeeded`` and ``failed`` use the correct tense. All of these options are now valid.
 
 
diff --git a/docs/docsite/rst/playbook_guide/playbooks_tags.rst b/docs/docsite/rst/playbook_guide/playbooks_tags.rst
index 4da0af02f4..bf01458f0d 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_tags.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_tags.rst
@@ -257,7 +257,7 @@ If you want tag inheritance, you probably want to use imports. However, using bo
 
 .. code-block:: yaml
 
-   - name: Apply the db tag to the include and to all tasks in db.yaml
+   - name: Apply the db tag to the include and to all tasks in db.yml
      include_tasks:
        file: db.yml
        # adds 'db' tag to tasks within db.yml
@@ -339,7 +339,7 @@ Once you have added tags to your tasks, includes, blocks, plays, roles, and impo
 * ``--tags tagged`` - run only tasks with at least one tag
 * ``--tags untagged`` - run only tasks with no tags
 
-For example, to run only tasks and blocks tagged ``configuration`` and ``packages`` in a very long playbook:
+For example, to run only tasks and blocks tagged either ``configuration`` or ``packages`` in a very long playbook:
 
 .. code-block:: bash
 
diff --git a/docs/docsite/rst/playbook_guide/playbooks_tests.rst b/docs/docsite/rst/playbook_guide/playbooks_tests.rst
index 71eaee838b..ccf6f9e642 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_tests.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_tests.rst
@@ -461,11 +461,11 @@ When looking to determine types, it may be tempting to use the ``type_debug`` fi
           a_list: ["a", "list"]
         assert:
           that:
-          # Note that a string is classed as also being "iterable", "sequence" and "mapping"
-          - a_string is string
+          # Note that a string is classed as also being "iterable" and "sequence", but not "mapping"
+          - a_string is string and a_string is iterable and a_string is sequence and a_string is not mapping
 
           # Note that a dictionary is classed as not being a "string", but is "iterable", "sequence" and "mapping"
-          - a_dictionary is not string and a_dictionary is mapping
+          - a_dictionary is not string and a_dictionary is iterable and a_dictionary is mapping
 
           # Note that a list is classed as not being a "string" or "mapping" but is "iterable" and "sequence"
           - a_list is not string and a_list is not mapping and a_list is iterable
diff --git a/docs/docsite/rst/plugins/test.rst b/docs/docsite/rst/plugins/test.rst
index 9bad4e72ff..7922c122f7 100644
--- a/docs/docsite/rst/plugins/test.rst
+++ b/docs/docsite/rst/plugins/test.rst
@@ -60,7 +60,7 @@ Tests will always have an ``_input`` and this is normally what is on the left si
 Using test plugins with lists
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-As mentioned above, one way to use tests is with the ``select`` familiy of filters (``select``, ``reject``, ``selectattr``, ``rejectattr``).
+As mentioned above, one way to use tests is with the ``select`` family of filters (``select``, ``reject``, ``selectattr``, ``rejectattr``).
 
 .. code-block:: YAML+Jinja
 
diff --git a/docs/docsite/rst/porting_guides/porting_guide_4.rst b/docs/docsite/rst/porting_guides/porting_guide_4.rst
index 4e91a30d63..5f45910b4f 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_4.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_4.rst
@@ -160,7 +160,7 @@ cisco.nxos
 junipernetworks.junos
 ~~~~~~~~~~~~~~~~~~~~~
 
-- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resuorce module.
+- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resource module.
 
 Porting Guide for v4.9.0
 ========================
diff --git a/docs/docsite/rst/porting_guides/porting_guide_5.rst b/docs/docsite/rst/porting_guides/porting_guide_5.rst
index 6257ccd1f2..7afc11e211 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_5.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_5.rst
@@ -173,7 +173,7 @@ vmware.vmware_rest
 
 - The vmware_rest 2.0.0 support vSphere 7.0.2 onwards.
 - vcenter_vm_storage_policy - the format of the ``disks`` parameter has changed.
-- vcenter_vm_storage_policy - the module has a new mandatory paramter: ``vm_home``.
+- vcenter_vm_storage_policy - the module has a new mandatory parameter: ``vm_home``.
 
 Major Changes
 -------------
@@ -412,7 +412,7 @@ community.hashi_vault
 junipernetworks.junos
 ~~~~~~~~~~~~~~~~~~~~~
 
-- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resuorce module.
+- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resource module.
 
 Porting Guide for v5.0.1
 ========================
@@ -618,7 +618,7 @@ amazon.aws
 ~~~~~~~~~~
 
 - amazon.aws collection - Due to the AWS SDKs announcing the end of support for Python less than 3.6 (https://boto3.amazonaws.com/v1/documentation/api/1.17.64/guide/migrationpy3.html) this collection now requires Python 3.6+ (https://github.com/ansible-collections/amazon.aws/pull/298).
-- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.18.0`` and ``boto3<1.15.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/502).
+- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.18.0`` and ``boto3<1.15.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/502).
 - ec2_instance - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance``.
 - ec2_instance_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_instance_info``.
 - ec2_vpc_endpoint - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_vpc_endpoint``.
@@ -680,7 +680,7 @@ cloudscale_ch.cloud
 community.aws
 ~~~~~~~~~~~~~
 
-- community.aws collection - The community.aws collection has dropped support for ``botocore<1.18.0`` and ``boto3<1.15.0`` (https://github.com/ansible-collections/community.aws/pull/711). Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/442).
+- community.aws collection - The community.aws collection has dropped support for ``botocore<1.18.0`` and ``boto3<1.15.0`` (https://github.com/ansible-collections/community.aws/pull/711). Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/442).
 
 community.ciscosmb
 ~~~~~~~~~~~~~~~~~~
diff --git a/docs/docsite/rst/porting_guides/porting_guide_6.rst b/docs/docsite/rst/porting_guides/porting_guide_6.rst
index a111451ffe..d7a0e98dd4 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_6.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_6.rst
@@ -273,7 +273,7 @@ Deprecated Features
 -------------------
 
 - The google.cloud collection is considered unmaintained and will be removed from Ansible 8 if no one starts maintaining it again before Ansible 8. See `the removal process for details on how this works <https://github.com/ansible-collections/overview/blob/main/removal_from_ansible.rst#cancelling-removal-of-an-unmaintained-collection>`__ (https://github.com/ansible-community/community-topics/issues/105).
-- The servicenow.servicenow collection has been deprecated by its maintainers (https://github.com/ServiceNowITOM/servicenow-ansible/pull/69) and will be removed from Ansible 7. It can still be installed manually, but it is suggested to swich to `servicenow.itsm <https://galaxy.ansible.com/servicenow/itsm>`__ instead (https://github.com/ansible-community/community-topics/issues/124).
+- The servicenow.servicenow collection has been deprecated by its maintainers (https://github.com/ServiceNowITOM/servicenow-ansible/pull/69) and will be removed from Ansible 7. It can still be installed manually, but it is suggested to switch to `servicenow.itsm <https://galaxy.ansible.com/servicenow/itsm>`__ instead (https://github.com/ansible-community/community-topics/issues/124).
 
 Porting Guide for v6.2.0
 ========================
@@ -576,7 +576,7 @@ Ansible-core
 amazon.aws
 ~~~~~~~~~~
 
-- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574).
+- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574).
 
 ansible.netcommon
 ~~~~~~~~~~~~~~~~~
@@ -678,12 +678,12 @@ cisco.nxos
 - The minimum required ansible.netcommon version has been bumped to v2.6.1.
 - Updated base plugin references to ansible.netcommon.
 - `nxos_facts` - change default gather_subset to `min` from `!config` (https://github.com/ansible-collections/cisco.nxos/issues/418).
-- nxos_file_copy has been rewritten as a module. This change also removes the dependency on pexpect for file_pull operation. Since this now uses AnsibleModule class for argspec validation, the validation messages will be slighlty different. Expect changes in the return payload in some cases. All functionality remains unchanged.
+- nxos_file_copy has been rewritten as a module. This change also removes the dependency on pexpect for file_pull operation. Since this now uses AnsibleModule class for argspec validation, the validation messages will be slightly different. Expect changes in the return payload in some cases. All functionality remains unchanged.
 
 community.aws
 ~~~~~~~~~~~~~
 
-- community.aws collection - The community.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/809).
+- community.aws collection - The community.aws collection has dropped support for ``botocore<1.19.0`` and ``boto3<1.16.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/809).
 - s3_bucket_notifications - refactor module to support SNS / SQS targets as well as the existing support for Lambda functions (https://github.com/ansible-collections/community.aws/issues/140).
 
 community.general
@@ -956,7 +956,7 @@ community.network
 junipernetworks.junos
 ~~~~~~~~~~~~~~~~~~~~~
 
-- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resuorce module.
+- 'router_id' options is deprecated from junos_ospf_interfaces, junos_ospfv2 and junos_ospfv3 resource module.
 
 purestorage.flasharray
 ~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/docsite/rst/porting_guides/porting_guide_7.rst b/docs/docsite/rst/porting_guides/porting_guide_7.rst
index bb8b01bfb0..5ac2f0f46c 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_7.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_7.rst
@@ -92,6 +92,35 @@ Networking
 
 No notable changes
 
+Porting Guide for v7.3.0
+========================
+
+Breaking Changes
+----------------
+
+hetzner.hcloud
+~~~~~~~~~~~~~~
+
+- inventory plugin - Python v3.5+ is now required.
+
+Major Changes
+-------------
+
+kubernetes.core
+~~~~~~~~~~~~~~~
+
+- refactor K8sAnsibleMixin into module_utils/k8s/ (https://github.com/ansible-collections/kubernetes.core/pull/481).
+
+Deprecated Features
+-------------------
+
+- Since the google.cloud collection seems to be maintained again, we `cancelled the removal process <https://github.com/ansible-collections/overview/blob/main/removal_from_ansible.rst#cancelling-removal-of-an-unmaintained-collection>`__. So contrary to an earlier announcement, this collection is NOT deprecated and will NOT be removed from Ansible 8 (https://github.com/ansible-community/community-topics/issues/105).
+
+community.general
+~~~~~~~~~~~~~~~~~
+
+- gitlab_runner - the option ``access_level`` will lose its default value in community.general 8.0.0. From that version on, you have set this option to ``ref_protected`` explicitly, if you want to have a protected runner (https://github.com/ansible-collections/community.general/issues/5925).
+
 Porting Guide for v7.2.0
 ========================
 
@@ -322,7 +351,7 @@ amazon.aws
 
 - Tags beginning with ``aws:`` will not be removed when purging tags, these tags are reserved by Amazon and may not be updated or deleted (https://github.com/ansible-collections/amazon.aws/issues/817).
 - amazon.aws collection - Support for ansible-core < 2.11 has been dropped (https://github.com/ansible-collections/amazon.aws/pull/1087).
-- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.21.0`` and ``boto3<1.18.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/934).
+- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.21.0`` and ``boto3<1.18.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/934).
 - amazon.aws collection - the ``profile`` parameter is now mutually exclusive with the ``aws_access_key``, ``aws_secret_key`` and ``security_token`` parameters (https://github.com/ansible-collections/amazon.aws/pull/834).
 - aws_az_info - the module alias ``aws_az_facts`` was deprecated in Ansible 2.9 and has now been removed (https://github.com/ansible-collections/amazon.aws/pull/832).
 - aws_s3 - the default value for ``ensure overwrite`` has been changed to ``different`` instead of ``always`` so that the module is idempotent by default (https://github.com/ansible-collections/amazon.aws/issues/811).
@@ -370,7 +399,7 @@ community.aws
 - cloudwatchlogs_log_group_metric_filter - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudwatchlogs_log_group_metric_filter``.
 - community.aws collection - Support for ansible-core < 2.11 has been dropped (https://github.com/ansible-collections/community.aws/pull/1541).
 - community.aws collection - The ``community.aws`` collection has now dropped support for and any requirements upon the original ``boto`` AWS SDK, and now uses the ``boto3``/``botocore`` AWS SDK (https://github.com/ansible-collections/community.aws/pull/898).
-- community.aws collection - The community.aws collection has dropped support for ``botocore<1.21.0`` and ``boto3<1.18.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/1362).
+- community.aws collection - The community.aws collection has dropped support for ``botocore<1.21.0`` and ``boto3<1.18.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/1362).
 - community.aws collection - the ``profile`` parameter is now mutually exclusive with the ``aws_access_key``, ``aws_secret_key`` and ``security_token`` parameters (https://github.com/ansible-collections/amazon.aws/pull/834).
 - ec2_eip - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip``.
 - ec2_eip_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.ec2_eip_info``.
@@ -481,7 +510,7 @@ Ansible-core
 amazon.aws
 ~~~~~~~~~~
 
-- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.20.0`` and ``boto3<1.17.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574).
+- amazon.aws collection - The amazon.aws collection has dropped support for ``botocore<1.20.0`` and ``boto3<1.17.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/amazon.aws/pull/574).
 - autoscaling_group - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group``.
 - autoscaling_group_info - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.autoscaling_group_info``.
 - cloudtrail - The module has been migrated from the ``community.aws`` collection. Playbooks using the Fully Qualified Collection Name for this module should be updated to use ``amazon.aws.cloudtrail``.
@@ -578,7 +607,7 @@ cisco.nxos
 community.aws
 ~~~~~~~~~~~~~
 
-- community.aws collection - The amazon.aws collection has dropped support for ``botocore<1.20.0`` and ``boto3<1.17.0``. Most modules will continue to work with older versions of the AWS SDK, however compatability with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/956).
+- community.aws collection - The amazon.aws collection has dropped support for ``botocore<1.20.0`` and ``boto3<1.17.0``. Most modules will continue to work with older versions of the AWS SDK, however compatibility with older versions of the SDK is not guaranteed and will not be tested. When using older versions of the SDK a warning will be emitted by Ansible (https://github.com/ansible-collections/community.aws/pull/956).
 
 community.docker
 ~~~~~~~~~~~~~~~~
diff --git a/lib/ansible/modules/package_facts.py b/lib/ansible/modules/package_facts.py
index 57c1d3ea75..ea3c699965 100644
--- a/lib/ansible/modules/package_facts.py
+++ b/lib/ansible/modules/package_facts.py
@@ -37,6 +37,8 @@ version_added: "2.5"
 requirements:
     - For 'portage' support it requires the C(qlist) utility, which is part of 'app-portage/portage-utils'.
     - For Debian-based systems C(python-apt) package must be installed on targeted hosts.
+    - For SUSE-based systems C(python3-rpm) package must be installed on targeted hosts.
+      This package is required because SUSE does not include RPM Python bindings by default.
 author:
   - Matthew Jones (@matburt)
   - Brian Coca (@bcoca)
diff --git a/lib/ansible/plugins/filter/combine.yml b/lib/ansible/plugins/filter/combine.yml
index 86788f3107..4787b447c5 100644
--- a/lib/ansible/plugins/filter/combine.yml
+++ b/lib/ansible/plugins/filter/combine.yml
@@ -34,9 +34,14 @@ DOCUMENTATION:
 EXAMPLES: |
 
     # ab => {'a':1, 'b':3, 'c': 4}
-    ab: {{ {'a':1, 'b':2} | combine({'b':3, 'c':4}) }}
+    ab: {{ {'a':1, 'b':2} | ansible.builtin.combine({'b':3, 'c':4}) }}
 
-    many: "{{ dict1 | combine(dict2, dict3, dict4) }}"
+    many: "{{ dict1 | ansible.builtin.combine(dict2, dict3, dict4) }}"
+    
+    # defaults => {'a':{'b':3, 'c':4}, 'd': 5}
+    # customization => {'a':{'c':20}}
+    # final => {'a':{'b':3, 'c':20}, 'd': 5}
+    final: "{{ defaults | ansible.builtin.combine(customization, recursive=true) }}"
 
 RETURN:
   _value:
diff --git a/lib/ansible/plugins/lookup/password.py b/lib/ansible/plugins/lookup/password.py
index 06ea8b36b1..fc2e8929e3 100644
--- a/lib/ansible/plugins/lookup/password.py
+++ b/lib/ansible/plugins/lookup/password.py
@@ -86,30 +86,30 @@ EXAMPLES = """
 - name: create a mysql user with a random password
   community.mysql.mysql_user:
     name: "{{ client }}"
-    password: "{{ lookup('ansible.builtin.password', 'credentials/' + client + '/' + tier + '/' + role + '/mysqlpassword length=15') }}"
+    password: "{{ lookup('ansible.builtin.password', 'credentials/' + client + '/' + tier + '/' + role + '/mysqlpassword', length=15) }}"
     priv: "{{ client }}_{{ tier }}_{{ role }}.*:ALL"
 
 - name: create a mysql user with a random password using only ascii letters
   community.mysql.mysql_user:
     name: "{{ client }}"
-    password: "{{ lookup('ansible.builtin.password', '/tmp/passwordfile chars=ascii_letters') }}"
+    password: "{{ lookup('ansible.builtin.password', '/tmp/passwordfile', chars=['ascii_letters']) }}"
     priv: '{{ client }}_{{ tier }}_{{ role }}.*:ALL'
 
 - name: create a mysql user with an 8 character random password using only digits
   community.mysql.mysql_user:
     name: "{{ client }}"
-    password: "{{ lookup('ansible.builtin.password', '/tmp/passwordfile length=8 chars=digits') }}"
+    password: "{{ lookup('ansible.builtin.password', '/tmp/passwordfile', length=8, chars=['digits']) }}"
     priv: "{{ client }}_{{ tier }}_{{ role }}.*:ALL"
 
 - name: create a mysql user with a random password using many different char sets
   community.mysql.mysql_user:
     name: "{{ client }}"
-    password: "{{ lookup('ansible.builtin.password', '/tmp/passwordfile chars=ascii_letters,digits,punctuation') }}"
+    password: "{{ lookup('ansible.builtin.password', '/tmp/passwordfile', chars=['ascii_letters', 'digits', 'punctuation']) }}"
     priv: "{{ client }}_{{ tier }}_{{ role }}.*:ALL"
 
 - name: create lowercase 8 character name for Kubernetes pod name
   ansible.builtin.set_fact:
-    random_pod_name: "web-{{ lookup('ansible.builtin.password', '/dev/null chars=ascii_lowercase,digits length=8') }}"
+    random_pod_name: "web-{{ lookup('ansible.builtin.password', '/dev/null', chars=['ascii_lowercase', 'digits'], length=8) }}"
 
 - name: create random but idempotent password
   ansible.builtin.set_fact: