Backportapaloosa 12 08 (#79565)

* Add Ansible community 6.7.0 porting guide (#79544)

(cherry picked from commit 3cdf589ca78fa1e0b5dc7330383e1047c35014a7)

* Fix hardcoded python call (#79520)

Co-authored-by: Lee Garrett <lgarrett@rocketjump.eu>
(cherry picked from commit 3fd519de57613d25ec6e252d023fc865b8e35876)

* Update windows_faq.rst (#79552)

`python-pip` changes to `python3-pip` for the Ubuntu 20.04 WSL distro

(cherry picked from commit 527abba86010629e21f8227c4234c393e4ee8122)

* Add Ansible community 7.1.0 porting guide (#79553)

(cherry picked from commit b1caba8b53603a0e39bc2103e72e2cb41c224fbf)

* fixed misleading setup example (#79495)

(cherry picked from commit bc13099e56410a933a48ce734dd575920e102866)

* Update docs for the `compile` sanity test. (#79562)

(cherry picked from commit 932a32153a4166d4efc3564f89177aa22935acf5)

* Remove obsolete legacy integration test docs. (#79563)

(cherry picked from commit 0f4afd7e6d584c19b7e95fe6682cb159c89925bc)

* fix: broken link (#79461)

(cherry picked from commit 6a7fb7d2ab07c5a124ac178929e56b5f6d8d04e5)

Co-authored-by: Anwesha Das <anwesha@das.community>
Co-authored-by: Lee Garrett <leegarrett@users.noreply.github.com>
Co-authored-by: Raymond Yee <raymond.yee@gmail.com>
Co-authored-by: Christian Adams <chadams@redhat.com>
Co-authored-by: zitatorocsik <zita.torocsik@gmail.com>
Co-authored-by: Matt Clay <matt@mystile.com>
Co-authored-by: Thomas Poindessous <thomas@poindessous.com>

10 files changed, 147 insertions, 202 deletions

diff --git a/docs/docsite/Makefile b/docs/docsite/Makefile
index 4e9cf2726f..f8e8759098 100644
--- a/docs/docsite/Makefile
+++ b/docs/docsite/Makefile
@@ -82,7 +82,7 @@ gettext_generate_rst: collections_meta config cli keywords testing
 ansible_structure:
 	# We must have python and python-packaging for the version_helper
 	# script so use it for version comparison
-	if python -c "import sys, packaging.version as p; sys.exit(not p.Version('$(MAJOR_VERSION)') >  p.Version('2.10'))" ; then \
+	if $(PYTHON) -c "import sys, packaging.version as p; sys.exit(not p.Version('$(MAJOR_VERSION)') >  p.Version('2.10'))" ; then \
 		echo "Creating symlinks in ansible_structure"; \
 		ln -sf ../rst/ansible_index.rst rst/index.rst; \
 		ln -sf ../dev_guide/ansible_index.rst rst/dev_guide/index.rst; \
diff --git a/docs/docsite/rst/dev_guide/developing_collections_testing.rst b/docs/docsite/rst/dev_guide/developing_collections_testing.rst
index 7f36dcdfa6..50d55ca5b5 100644
--- a/docs/docsite/rst/dev_guide/developing_collections_testing.rst
+++ b/docs/docsite/rst/dev_guide/developing_collections_testing.rst
@@ -4,7 +4,7 @@
 Testing collections
 *******************
 
-Testing your collection ensures that your code works well and integrates well with the rest of the Ansible ecosystem. Your collection should pass the general compile and sanity tests for Ansible code. You should also add unit tests to cover the code in your collection and integration tests to cover the interactions between your collection and ansible-core.
+Testing your collection ensures that your code works well and integrates well with the rest of the Ansible ecosystem. Your collection should pass the sanity tests for Ansible code. You should also add unit tests to cover the code in your collection and integration tests to cover the interactions between your collection and ansible-core.
 
 .. contents::
    :local:
@@ -15,20 +15,20 @@ Testing tools
 
 The main tool for testing collections is ``ansible-test``, Ansible's testing tool described in :ref:`developing_testing` and provided by both the ``ansible`` and ``ansible-core`` packages.
 
-You can run several compile and sanity checks, as well as run unit and integration tests for plugins using ``ansible-test``. When you test collections, test against the ansible-core version(s) you are targeting.
+You can run several sanity tests, as well as run unit and integration tests for plugins using ``ansible-test``. When you test collections, test against the ansible-core version(s) you are targeting.
 
 You must always execute ``ansible-test`` from the root directory of a collection. You can run ``ansible-test`` in Docker containers without installing any special requirements. The Ansible team uses this approach in Azure Pipelines both in the ansible/ansible GitHub repository and in the large community collections such as `community.general <https://github.com/ansible-collections/community.general/>`_ and `community.network <https://github.com/ansible-collections/community.network/>`_. The examples below demonstrate running tests in Docker containers.
 
-Compile and sanity tests
-------------------------
+Sanity tests
+------------
 
-To run all compile and sanity tests:
+To run all sanity tests:
 
 .. code-block:: shell-session
 
     ansible-test sanity --docker default -v
 
-See :ref:`testing_compile` and :ref:`testing_sanity` for more information. See the :ref:`full list of sanity tests <all_sanity_tests>` for details on the sanity tests and how to fix identified issues.
+See :ref:`testing_sanity` for more information. See the :ref:`full list of sanity tests <all_sanity_tests>` for details on the sanity tests and how to fix identified issues.
 
 Adding unit tests
 -----------------
diff --git a/docs/docsite/rst/dev_guide/testing.rst b/docs/docsite/rst/dev_guide/testing.rst
index a587a74608..6b4716ddfe 100644
--- a/docs/docsite/rst/dev_guide/testing.rst
+++ b/docs/docsite/rst/dev_guide/testing.rst
@@ -26,9 +26,6 @@ Types of tests
 
 At a high level we have the following classifications of tests:
 
-:compile:
-  * :ref:`testing_compile`
-  * Test python code against a variety of Python versions.
 :sanity:
   * :ref:`testing_sanity`
   * Sanity tests are made up of scripts and tools used to perform static code analysis.
diff --git a/docs/docsite/rst/dev_guide/testing/sanity/compile.rst b/docs/docsite/rst/dev_guide/testing/sanity/compile.rst
index 222f94e485..507e30981a 100644
--- a/docs/docsite/rst/dev_guide/testing/sanity/compile.rst
+++ b/docs/docsite/rst/dev_guide/testing/sanity/compile.rst
@@ -1,4 +1,32 @@
+.. _testing_compile:
+
 compile
 =======
 
-See :ref:`testing_compile` for more information.
+All Python source files must successfully compile using all supported Python versions.
+
+.. note::
+
+   The list of supported Python versions is dependent on the version of ``ansible-core`` that you are using.
+   Make sure you consult the version of the documentation which matches your ``ansible-core`` version.
+
+Controller code, including plugins in Ansible Collections, must support the following Python versions:
+
+- 3.11
+- 3.10
+- 3.9
+
+Code which runs on targets (``modules`` and ``module_utils``) must support all controller supported Python versions,
+as well as the additional Python versions supported only on targets:
+
+- 3.8
+- 3.7
+- 3.6
+- 3.5
+- 2.7
+
+.. note::
+
+   Ansible Collections can be
+   `configured <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/config/config.yml>_`
+   to support a subset of the target-only Python versions.
diff --git a/docs/docsite/rst/dev_guide/testing_compile.rst b/docs/docsite/rst/dev_guide/testing_compile.rst
index a4119f55d7..2f258c8b07 100644
--- a/docs/docsite/rst/dev_guide/testing_compile.rst
+++ b/docs/docsite/rst/dev_guide/testing_compile.rst
@@ -1,76 +1,8 @@
 :orphan:
 
-.. _testing_compile:
 
 *************
 Compile Tests
 *************
 
-.. contents:: Topics
-
-Overview
-========
-
-Compile tests check source files for valid syntax on all supported python versions:
-
-- 2.4 (Ansible 2.3 only)
-- 2.6
-- 2.7
-- 3.5
-- 3.6
-- 3.7
-- 3.8
-- 3.9
-
-NOTE: In Ansible 2.4 and earlier the compile test was provided by a dedicated sub-command ``ansible-test compile`` instead of a sanity test using ``ansible-test sanity --test compile``.
-
-Running compile tests locally
-=============================
-
-Compile tests can be run across the whole code base by doing:
-
-.. code:: shell
-
-    cd /path/to/ansible/source
-    source hacking/env-setup
-    ansible-test sanity --test compile
-
-Against a single file by doing:
-
-.. code:: shell
-
-   ansible-test sanity --test compile lineinfile
-
-Or against a specific Python version by doing:
-
-.. code:: shell
-
-   ansible-test sanity --test compile --python 2.7 lineinfile
-
-For advanced usage see the help:
-
-.. code:: shell
-
-   ansible-test sanity --help
-
-
-Installing dependencies
-=======================
-
-``ansible-test`` has a number of dependencies , for ``compile`` tests we suggest running the tests with ``--local``, which is the default
-
-The dependencies can be installed using the ``--requirements`` argument. For example:
-
-.. code:: shell
-
-   ansible-test sanity --test compile --requirements lineinfile
-
-
-
-The full list of requirements can be found at `test/lib/ansible_test/_data/requirements <https://github.com/ansible/ansible/tree/devel/test/lib/ansible_test/_data/requirements>`_. Requirements files are named after their respective commands. See also the `constraints <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/requirements/constraints.txt>`_ applicable to all commands.
-
-
-Extending compile tests
-=======================
-
-If you believe changes are needed to the compile tests please add a comment on the `Testing Working Group Agenda <https://github.com/ansible/community/blob/main/meetings/README.md>`_ so it can be discussed.
+This page has moved to :ref:`testing_compile`.
diff --git a/docs/docsite/rst/dev_guide/testing_integration.rst b/docs/docsite/rst/dev_guide/testing_integration.rst
index b335826119..915281d02c 100644
--- a/docs/docsite/rst/dev_guide/testing_integration.rst
+++ b/docs/docsite/rst/dev_guide/testing_integration.rst
@@ -187,13 +187,6 @@ Container images are updated regularly. To see the current list of container ima
 
 The list is under the **target docker images and supported python version** heading.
 
-Legacy Cloud Tests
-==================
-
-Some of the cloud tests run as normal integration tests, and others run as legacy tests; see the
-:ref:`testing_integration_legacy` page for more information.
-
-
 Other configuration for Cloud Tests
 ===================================
 
diff --git a/docs/docsite/rst/dev_guide/testing_integration_legacy.rst b/docs/docsite/rst/dev_guide/testing_integration_legacy.rst
deleted file mode 100644
index 115fde6c93..0000000000
--- a/docs/docsite/rst/dev_guide/testing_integration_legacy.rst
+++ /dev/null
@@ -1,114 +0,0 @@
-:orphan:
-
-.. _testing_integration_legacy:
-
-*******************************************
-Testing using the Legacy Integration system
-*******************************************
-
-.. contents:: Topics
-
-This page details how to run the integration tests that haven't been ported to the new ``ansible-test`` framework.
-
-The following areas are still tested using the legacy ``make tests`` command:
-
-* amazon (some)
-* azure
-* cloudflare
-* cloudscale
-* cloudstack
-* consul
-* exoscale
-* gce
-* jenkins
-* rackspace
-
-Over time the above list will be reduced as tests are ported to the ``ansible-test`` framework.
-
-
-Running Cloud Tests
-====================
-
-Cloud tests exercise capabilities of cloud modules (for example, ec2_key).  These are
-not 'tests run in the cloud' so much as tests that use the cloud modules
-and are organized by cloud provider.
-
-Some AWS tests may use environment variables. It is recommended to either unset any AWS environment variables( such as ``AWS_DEFAULT_PROFILE``, ``AWS_SECRET_ACCESS_KEY``, and so on) or be sure that the environment variables match the credentials provided in ``credentials.yml`` to ensure the tests run with consistency to their full capability on the expected account. See `AWS CLI docs <https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html>`_ for information on creating a profile.
-
-Subsets of tests may be run by ``#commenting`` out unnecessary roles in the appropriate playbook, such as ``test/integration/amazon.yml``.
-
-In order to run cloud tests, you must provide access credentials in a file
-named ``credentials.yml``. A sample credentials file named
-``credentials.template`` is available for syntax help.
-
-Provide cloud credentials:
-
-.. code-block:: shell-session
-
-    cp credentials.template credentials.yml
-    ${EDITOR:-vi} credentials.yml
-
-
-Other configuration
-===================
-
-In order to run some tests, you must provide access credentials in a file named
-``credentials.yml``. A sample credentials file named ``credentials.template`` is available
-for syntax help.
-
-IAM policies for AWS
-====================
-
-In order to run the tests in an AWS account ansible needs fairly wide ranging powers which
-can be provided to a dedicated user or temporary credentials using a specific policy
-configured in the AWS account.
-
-testing-iam-policy.json.j2
---------------------------
-
-The testing-iam-policy.json.j2 file contains a policy which can be given to the user
-running the tests to give close to minimum rights required to run the tests.  Please note
-that this does not fully restrict the user; The user has wide privileges for viewing
-account definitions and is also able to manage some resources that are not related to
-testing (for example, AWS lambdas with different names) primarily due to the limitations of the
-Amazon ARN notation.  At the very least the policy limits the user to one region, however
-tests should not be run in a primary production account in any case.
-
-Other Definitions required
---------------------------
-
-Apart from installing the policy and giving it to the user identity running
-the tests, a lambda role `ansible_integration_tests` has to be created which
-has lambda basic execution privileges.
-
-
-Running Tests
-=============
-
-The tests are invoked through the ``Makefile``.
-
-If you haven't already got Ansible available use the local checkout by doing:
-
-.. code-block:: shell-session
-
-  source hacking/env-setup
-
-Run the tests by doing:
-
-.. code-block:: shell-session
-
-  cd test/integration/
-  # TARGET is the name of the test from the list at the top of this page
-  #make TARGET
-  # for example
-  make amazon
-  # To run all cloud tests you can do:
-  make cloud
-
-.. warning:: Possible cost of running cloud tests
-
-   Running cloud integration tests will create and destroy cloud
-   resources. Running these tests may result in additional fees associated with
-   your cloud account. Care is taken to ensure that created resources are
-   removed. However, it is advisable to inspect your AWS console to ensure no
-   unexpected resources are running.
diff --git a/docs/docsite/rst/os_guide/windows_faq.rst b/docs/docsite/rst/os_guide/windows_faq.rst
index 9732572326..f582d7db20 100644
--- a/docs/docsite/rst/os_guide/windows_faq.rst
+++ b/docs/docsite/rst/os_guide/windows_faq.rst
@@ -57,7 +57,7 @@ can be run in the bash terminal:
 .. code-block:: shell
 
     sudo apt-get update
-    sudo apt-get install python-pip git libffi-dev libssl-dev -y
+    sudo apt-get install python3-pip git libffi-dev libssl-dev -y
     pip install --user ansible pywinrm
 
 To run Ansible from source instead of a release on the WSL, simply uninstall the pip
diff --git a/docs/docsite/rst/porting_guides/porting_guide_6.rst b/docs/docsite/rst/porting_guides/porting_guide_6.rst
index 87756b2e17..a111451ffe 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_6.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_6.rst
@@ -99,6 +99,58 @@ Networking
 
 No notable changes
 
+Porting Guide for v6.7.0
+========================
+
+Known Issues
+------------
+
+community.routeros
+~~~~~~~~~~~~~~~~~~
+
+- api_modify - when limits for entries in ``queue tree`` are defined as human readable - for example ``25M`` -, the configuration will be correctly set in ROS, but the module will indicate the item is changed on every run even when there was no change done. This is caused by the ROS API which returns the number in bytes - for example ``25000000`` (which is inconsistent with the CLI behavior). In order to mitigate that, the limits have to be defined in bytes (those will still appear as human readable in the ROS CLI) (https://github.com/ansible-collections/community.routeros/pull/131).
+- api_modify, api_info - ``routing ospf area``, ``routing ospf area range``, ``routing ospf instance``, ``routing ospf interface-template`` paths are not fully implemeted for ROS6 due to the significat changes between ROS6 and ROS7 (https://github.com/ansible-collections/community.routeros/pull/131).
+
+Major Changes
+-------------
+
+cisco.meraki
+~~~~~~~~~~~~
+
+- meraki_mr_l7_firewall - New module
+- meraki_webhook_payload_template - New module
+
+community.zabbix
+~~~~~~~~~~~~~~~~
+
+- all modules are opting away from zabbix-api and using httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate
+- zabbix_agent and zabbix_proxy roles are opting away from zabbix-api and use httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate
+
+containers.podman
+~~~~~~~~~~~~~~~~~
+
+- New become plugin - podman_unshare
+- Podman generate systemd module
+
+fortinet.fortimanager
+~~~~~~~~~~~~~~~~~~~~~
+
+- Fix compatibility issue for ansible 2.9.x and ansible-base 2.10.x.
+- support Ansible changelogs.
+
+fortinet.fortios
+~~~~~~~~~~~~~~~~
+
+- Support FortiOS v7.0.6, v7.0.7, v7.0.8, v7.2.1, v7.2.2.
+
+Deprecated Features
+-------------------
+
+community.general
+~~~~~~~~~~~~~~~~~
+
+- Please note that some tools, like the VScode plugin (https://github.com/ansible/vscode-ansible/issues/573), or ``ansible-doc --list --type module``, suggest to replace the correct FQCNs for modules and actions in community.general with internal names that have more than three components. For example, ``community.general.ufw`` is suggested to be replaced by ``community.general.system.ufw``. While these longer names do work, they are considered **internal names** by the collection and are subject to change and be removed at all time. They **will** be removed in community.general 6.0.0 and result in deprecation messages. Avoid using these internal names, and use general three-component FQCNs (``community.general.<name_of_module>``) instead (https://github.com/ansible-collections/community.general/pull/5373).
+
 Porting Guide for v6.6.0
 ========================
 
@@ -131,6 +183,12 @@ community.general
 
 - newrelic_deployment - removed New Relic v1 API, added support for v2 API (https://github.com/ansible-collections/community.general/pull/5341).
 
+fortinet.fortimanager
+~~~~~~~~~~~~~~~~~~~~~
+
+- Many fixes for Ansible sanity test warnings & errors.
+- Support FortiManager Schema 7.2.0 , 98 new modules
+
 Deprecated Features
 -------------------
 
diff --git a/docs/docsite/rst/porting_guides/porting_guide_7.rst b/docs/docsite/rst/porting_guides/porting_guide_7.rst
index 5c3d6faecd..737cf3e380 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_7.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_7.rst
@@ -92,6 +92,57 @@ Networking
 
 No notable changes
 
+Porting Guide for v7.1.0
+========================
+
+Added Collections
+-----------------
+
+- grafana.grafana (version 1.1.0)
+
+Known Issues
+------------
+
+community.routeros
+~~~~~~~~~~~~~~~~~~
+
+- api_modify - when limits for entries in ``queue tree`` are defined as human readable - for example ``25M`` -, the configuration will be correctly set in ROS, but the module will indicate the item is changed on every run even when there was no change done. This is caused by the ROS API which returns the number in bytes - for example ``25000000`` (which is inconsistent with the CLI behavior). In order to mitigate that, the limits have to be defined in bytes (those will still appear as human readable in the ROS CLI) (https://github.com/ansible-collections/community.routeros/pull/131).
+- api_modify, api_info - ``routing ospf area``, ``routing ospf area range``, ``routing ospf instance``, ``routing ospf interface-template`` paths are not fully implemeted for ROS6 due to the significat changes between ROS6 and ROS7 (https://github.com/ansible-collections/community.routeros/pull/131).
+
+Major Changes
+-------------
+
+cisco.meraki
+~~~~~~~~~~~~
+
+- meraki_mr_l7_firewall - New module
+- meraki_webhook_payload_template - New module
+
+community.zabbix
+~~~~~~~~~~~~~~~~
+
+- all modules are opting away from zabbix-api and using httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate
+- zabbix_agent and zabbix_proxy roles are opting away from zabbix-api and use httpapi ansible.netcommon plugin. We will support zabbix-api for backwards compatibility until next major release. See our README.md for more information about how to migrate
+
+containers.podman
+~~~~~~~~~~~~~~~~~
+
+- New become plugin - podman_unshare
+- Podman generate systemd module
+
+fortinet.fortios
+~~~~~~~~~~~~~~~~
+
+- Support FortiOS v7.0.6, v7.0.7, v7.0.8, v7.2.1, v7.2.2.
+
+Deprecated Features
+-------------------
+
+community.general
+~~~~~~~~~~~~~~~~~
+
+- The ``sap`` modules ``sapcar_extract``, ``sap_task_list_execute``, and ``hana_query``, will be removed from this collection in community.general 7.0.0 and replaced with redirects to ``community.sap_libs``. If you want to continue using these modules, make sure to also install ``community.sap_libs`` (it is part of the Ansible package) (https://github.com/ansible-collections/community.general/pull/5614).
+
 Porting Guide for v7.0.0
 ========================