05 12 backportapalooza (#77787)

* stub out ovirt dev guide with pointer to new location (#77751)

(cherry picked from commit 5e22fe21fd941b4b977d8ac4632a3f0d4eba68f2)

* Docsite/communication.rst: fix formatting (#77760)

(cherry picked from commit 97e574fe6ea7a73ef8e42140e8be32c8cdbcaece)

* Updated the playbook section in this docs (#77747)

(cherry picked from commit 42086c14a36ccf3eb16b10350852ba1ffc2ed6d1)

* 2.13 GA has been bumped up a week to release on May 16 (#77772)

(cherry picked from commit 75bc6305650607c550f002aa06dfdbc399efe758)

* Fix plugin dev examples (#77759)

* Fix plugin dev examples

* Update docs/docsite/rst/dev_guide/developing_plugins.rst

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

* docs: Update ansible-core release date in Ansible roadmap (#77775)

(cherry picked from commit 235f2598b1b3f5dd3576e7d9fac0938013ae0612)

* revamp basic concepts docs (#77748)

(cherry picked from commit 8e9140341256d2bbad4ea8ce81763be037e6fc88)

* core-2.13 - update release table (#77780)

(cherry picked from commit 6230244537b57fddf1bf822c74ffd0061eb240cc)

* clarify Ansible EOL details (#77778)

* clarify Ansible EOL details: update docs/docsite/rst/reference_appendices/release_and_maintenance.rst
Co-authored-by: Felix Fontein <felix@fontein.de>

(cherry picked from commit 654fff05e6f9ae51084dbc866ca30020aa960fb2)

* Update url to quickstart video. (#77779)

(cherry picked from commit f75bb09a8b60870d640835f4309d318539fdef96)

Co-authored-by: Andrew Klychkov <aklychko@redhat.com>
Co-authored-by: Desmond Obisi <51109125+DesmondSanctity@users.noreply.github.com>
Co-authored-by: Matt Martz <matt@sivel.net>
Co-authored-by: Mario Lenz <m@riolenz.de>
Co-authored-by: David Moreau Simard <moi@dmsimard.com>
Co-authored-by: Brian Coca <bcoca@users.noreply.github.com>
Co-authored-by: Tabah Baridule <dulemartins07@gmail.com>
Co-authored-by: Matt Davis <6775756+nitzmahone@users.noreply.github.com>

9 files changed, 70 insertions, 236 deletions

diff --git a/docs/docsite/rst/community/communication.rst b/docs/docsite/rst/community/communication.rst
index d50be0e621..91ef30a512 100644
--- a/docs/docsite/rst/community/communication.rst
+++ b/docs/docsite/rst/community/communication.rst
@@ -117,6 +117,7 @@ Many of our community `Working Groups <https://github.com/ansible/community/wiki
 - `Linode Working Group <https://github.com/ansible/community/wiki/Linode>`_ - Matrix: `#linode:ansible.com <https://matrix.to:/#/#linode:ansible.com>`_ | IRC: ``#ansible-linode``
 - `Molecule Working Group <https://github.com/ansible/community/wiki/Molecule>`_ (`testing platform for Ansible playbooks and roles <https://molecule.readthedocs.io>`_) - Matrix: `#molecule:ansible.im <https://matrix.to:/#/#molecule:ansible.im>`_ | IRC: ``#ansible-molecule``
 - `Network Working Group <https://github.com/ansible/community/wiki/Network>`_ - Matrix: `#network:ansible.com <https://matrix.to:/#/#network:ansible.com>`_ | IRC: ``#ansible-network``
+- `PostgreSQL Working Group <https://github.com/ansible-collections/community.postgresql/wiki/PostgreSQL-Working-Group>`_ - Matrix: `#postgresql:ansible.com <https://matrix.to:/#/#postgresql:ansible.com>`_
 - `Remote Management Working Group <https://github.com/ansible/community/issues/409>`_ - Matrix: `#devel:ansible.com <https://matrix.to:/#/#devel:ansible.com>`_ | IRC: ``#ansible-devel``
 - `Testing Working Group <https://github.com/ansible/community/wiki/Testing>`_  - Matrix: `#devel:ansible.com <https://matrix.to:/#/#devel:ansible.com>`_ | IRC: ``#ansible-devel``
 - `VMware Working Group <https://github.com/ansible/community/wiki/VMware>`_ - Matrix: `#vmware:ansible.com <https://matrix.to:/#/#vmware:ansible.com>`_ | IRC: ``#ansible-vmware``
diff --git a/docs/docsite/rst/dev_guide/developing_collections_structure.rst b/docs/docsite/rst/dev_guide/developing_collections_structure.rst
index 585087a4c8..51f65685c5 100644
--- a/docs/docsite/rst/dev_guide/developing_collections_structure.rst
+++ b/docs/docsite/rst/dev_guide/developing_collections_structure.rst
@@ -185,6 +185,13 @@ This will keep the playbook in 'collection context', as if you had added ``colle
 
 You can have most of the subdirectories you would expect, such ``files/``, ``vars/`` or  ``templates/`` but no ``roles/`` since those are handled already in the collection.
 
+Also, playbooks within a collection follow the same guidelines as any playbooks except for these few adjustments:
+
+ - Directory: It must be in ``/playbooks directory``.
+ - Hosts: The host should be defined as a variable so the users of a playbook do not mistakenly run the plays against their entire inventory (if the host is set to all). For example - ``hosts: '{{target|default("all")}}'``.
+
+To run the plays, users can now use such commands as ``ansible-playbook --e 'targets=webservers'`` or ``ansible-playbook --limit webservers``. Either way, the collection owner should document their playbooks and how to use them in the ``/docs`` folder or ``README`` file.
+
 .. _developing_collections_tests_directory:
 
 tests directory
diff --git a/docs/docsite/rst/dev_guide/developing_plugins.rst b/docs/docsite/rst/dev_guide/developing_plugins.rst
index e6529075da..a24f39727b 100644
--- a/docs/docsite/rst/dev_guide/developing_plugins.rst
+++ b/docs/docsite/rst/dev_guide/developing_plugins.rst
@@ -225,7 +225,7 @@ but with an extra option so you can see how configuration works in Ansible versi
 
     # not only visible to ansible-doc, it also 'declares' the options the plugin requires and how to configure them.
     DOCUMENTATION = '''
-    callback: timer
+    name: timer
     callback_type: aggregate
     requirements:
         - enable in configuration
@@ -357,8 +357,8 @@ Here's a simple lookup plugin implementation --- this lookup returns the content
     __metaclass__ = type
 
     DOCUMENTATION = """
-      lookup: file
-      author: Daniel Hokka Zakrisson <daniel@hozac.com>
+      name: file
+      author: Daniel Hokka Zakrisson (@dhozac) <daniel@hozac.com>
       version_added: "0.9"  # for collections, use the collection version, not the Ansible version
       short_description: read file contents
       description:
diff --git a/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst b/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst
index 2d72fac291..4316bce5cf 100644
--- a/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst
+++ b/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst
@@ -3,218 +3,5 @@
 oVirt Ansible Modules
 =====================
 
-The set of modules for interacting with oVirt/RHV are currently part of the community.general collection (on `Galaxy <https://galaxy.ansible.com/community/general>`_, source code `repository <https://github.com/ansible-collections/community.general/tree/main/plugins/modules/cloud/ovirt>`_). This document serves as developer coding guidelines for creating oVirt/RHV modules.
 
-.. contents::
-   :local:
-
-Naming
-------
-
--  All modules should start with an ``ovirt_`` prefix.
--  All modules should be named after the resource it manages in singular
-   form.
--  All modules that gather information should have a ``_info``
-   suffix.
-
-Interface
----------
-
--  Every module should return the ID of the resource it manages.
--  Every module should return the dictionary of the resource it manages.
--  Never change the name of the parameter, as we guarantee backward
-   compatibility. Use aliases instead.
--  If a parameter can't achieve idempotency for any reason, please
-   document it.
-
-Interoperability
-----------------
-
--  All modules should work against all minor versions of
-   version 4 of the API. Version 3 of the API is not supported.
-
-Libraries
----------
-
--  All modules should use ``ovirt_full_argument_spec`` or
-   ``ovirt_info_full_argument_spec`` to pick up the standard input (such
-   as auth and ``fetch_nested``).
--  All modules should use ``extends_documentation_fragment``: ovirt to go
-   along with ``ovirt_full_argument_spec``.
--  All info modules should use ``extends_documentation_fragment``:
-   ``ovirt_info`` to go along with ``ovirt_info_full_argument_spec``.
--  Functions that are common to all modules should be implemented in the
-   ``module_utils/ovirt.py`` file, so they can be reused.
--  Python SDK version 4 must be used.
-
-New module development
-----------------------
-
-Please read :ref:`developing_modules`,
-first to know what common properties, functions and features every module must
-have.
-
-In order to achieve idempotency of oVirt entity attributes, a helper class
-was created. The first thing you need to do is to extend this class and override a few
-methods:
-
-.. code:: python
-
-    try:
-        import ovirtsdk4.types as otypes
-    except ImportError:
-        pass
-
-    from ansible.module_utils.ovirt import (
-        BaseModule,
-        equal
-    )
-
-    class ClustersModule(BaseModule):
-
-        # The build method builds the entity we want to create.
-        # Always be sure to build only the parameters the user specified
-        # in their yaml file, so we don't change the values which we shouldn't
-        # change. If you set the parameter to None, nothing will be changed.
-        def build_entity(self):
-            return otypes.Cluster(
-                name=self.param('name'),
-                comment=self.param('comment'),
-                description=self.param('description'),
-            )
-
-        # The update_check method checks if the update is needed to be done on
-        # the entity. The equal method doesn't check the values which are None,
-        # which means it doesn't check the values which user didn't set in yaml.
-        # All other values are checked and if there is found some mismatch,
-        # the update method is run on the entity, the entity is build by
-        # 'build_entity' method. You don't have to care about calling the update,
-        # it's called behind the scene by the 'BaseModule' class.
-        def update_check(self, entity):
-            return (
-                equal(self.param('comment'), entity.comment)
-                and equal(self.param('description'), entity.description)
-            )
-
-The code above handle the check if the entity should be updated, so we
-don't update the entity if not needed and also it construct the needed
-entity of the SDK.
-
-.. code:: python
-
-    from ansible.module_utils.basic import AnsibleModule
-    from ansible.module_utils.ovirt import (
-        check_sdk,
-        create_connection,
-        ovirt_full_argument_spec,
-    )
-
-    # This module will support two states of the cluster,
-    # either it will be present or absent. The user can
-    # specify three parameters: name, comment and description,
-    # The 'ovirt_full_argument_spec' function, will merge the
-    # parameters created here with some common one like 'auth':
-    argument_spec = ovirt_full_argument_spec(
-        state=dict(
-            choices=['present', 'absent'],
-            default='present',
-        ),
-        name=dict(default=None, required=True),
-        description=dict(default=None),
-        comment=dict(default=None),
-    )
-
-    # Create the Ansible module, please always implement the
-    # feature called 'check_mode', for 'create', 'update' and
-    # 'delete' operations it's implemented by default in BaseModule:
-    module = AnsibleModule(
-        argument_spec=argument_spec,
-        supports_check_mode=True,
-    )
-
-    # Check if the user has Python SDK installed:
-    check_sdk(module)
-
-    try:
-        auth = module.params.pop('auth')
-
-        # Create the connection to the oVirt engine:
-        connection = create_connection(auth)
-
-        # Create the service which manages the entity:
-        clusters_service = connection.system_service().clusters_service()
-
-        # Create the module which will handle create, update and delete flow:
-        clusters_module = ClustersModule(
-            connection=connection,
-            module=module,
-            service=clusters_service,
-        )
-
-        # Check the state and call the appropriate method:
-        state = module.params['state']
-        if state == 'present':
-            ret = clusters_module.create()
-        elif state == 'absent':
-            ret = clusters_module.remove()
-
-        # The return value of the 'create' and 'remove' method is dictionary
-        # with the 'id' of the entity we manage and the type of the entity
-        # with filled in attributes of the entity. The 'change' status is
-        # also returned by those methods:
-        module.exit_json(**ret)
-    except Exception as e:
-        # Modules can't raises exception, it always must exit with
-        # 'module.fail_json' in case of exception. Always use
-        # 'exception=traceback.format_exc' for debugging purposes:
-        module.fail_json(msg=str(e), exception=traceback.format_exc())
-    finally:
-        # Logout only in case the user passed the 'token' in 'auth'
-        # parameter:
-        connection.close(logout=auth.get('token') is None)
-
-If your module must support action handling (for example,
-virtual machine start) you must ensure that you handle the states of the
-virtual machine correctly, and document the behavior of the
-module:
-
-.. code:: python
-
-        if state == 'running':
-            ret = vms_module.action(
-                action='start',
-                post_action=vms_module._post_start_action,
-                action_condition=lambda vm: (
-                    vm.status not in [
-                        otypes.VmStatus.MIGRATING,
-                        otypes.VmStatus.POWERING_UP,
-                        otypes.VmStatus.REBOOT_IN_PROGRESS,
-                        otypes.VmStatus.WAIT_FOR_LAUNCH,
-                        otypes.VmStatus.UP,
-                        otypes.VmStatus.RESTORING_STATE,
-                    ]
-                ),
-                wait_condition=lambda vm: vm.status == otypes.VmStatus.UP,
-                # Start action kwargs:
-                use_cloud_init=use_cloud_init,
-                use_sysprep=use_sysprep,
-                # ...
-            )
-
-As you can see from the preceding example, the ``action`` method accepts the ``action_condition`` and
-``wait_condition``, which are methods which accept the virtual machine
-object as a parameter, so you can check whether the virtual
-machine is in a proper state before the action. The rest of the
-parameters are for the ``start`` action. You may also handle pre-
-or post- action tasks by defining ``pre_action`` and ``post_action``
-parameters.
-
-Testing
--------
-
--  Integration testing is currently done in oVirt's CI system
-   `on Jenkins <https://jenkins.ovirt.org/view/All/job/ovirt-system-tests_ansible-suite-master/>`__
-   and
-   `on GitHub <https://github.com/oVirt/ovirt-system-tests/tree/master/ansible-suite-master/>`__.
--  Please consider using these integration tests if you create a new module or add a new feature to an existing
-   module.
+See the `ovirt.ovirt collection documentation <https://github.com/oVirt/ovirt-ansible-collection/blob/master/README-developers.md>`_ for details on how to contribute to this collection.
\ No newline at end of file
diff --git a/docs/docsite/rst/reference_appendices/release_and_maintenance.rst b/docs/docsite/rst/reference_appendices/release_and_maintenance.rst
index 0708f08c5d..51a24931c2 100644
--- a/docs/docsite/rst/reference_appendices/release_and_maintenance.rst
+++ b/docs/docsite/rst/reference_appendices/release_and_maintenance.rst
@@ -54,6 +54,11 @@ The Ansible community team typically releases two major versions of the communit
 
 Starting with version 2.10, the Ansible community team guarantees maintenance for only one major community package release at a time. For example, when Ansible 4.0.0 gets released, the team will stop making new 3.x releases. Community members may maintain older versions if desired.
 
+.. note:: 
+    
+   Each Ansible EOL version may issue one final maintenance release at or shortly after the first release of the next version. When this happens, the final maintenance release is EOL at the date it releases. 
+
+
 .. note::
 
    Older, unmaintained versions of the Ansible community package might contain unfixed security vulnerabilities (*CVEs*). If you are using a release of the Ansible community package that is no longer maintained, we strongly encourage you to upgrade as soon as possible in order to benefit from the latest features and security fixes.
@@ -75,8 +80,8 @@ This table links to the changelogs for each major Ansible release. These changel
 Ansible Community Package Release       Status                          Core version dependency
 ==================================      ============================    =========================
 6.0.0                                   In development (unreleased)     2.13
-`5.x Changelogs`_                       Current (latest stable)         2.12
-`4.x Changelogs`_                       End of life after 4.10          2.11
+`5.x Changelogs`_                       Current (EOL after 5.10)        2.12
+`4.x Changelogs`_                       Unmaintained (end of life)      2.11
 `3.x Changelogs`_                       Unmaintained (end of life)      2.10
 `2.10 Changelogs`_                      Unmaintained (end of life)      2.10
 ==================================      ============================    =========================
diff --git a/docs/docsite/rst/roadmap/COLLECTIONS_6.rst b/docs/docsite/rst/roadmap/COLLECTIONS_6.rst
index b0ef89222d..957c989df5 100644
--- a/docs/docsite/rst/roadmap/COLLECTIONS_6.rst
+++ b/docs/docsite/rst/roadmap/COLLECTIONS_6.rst
@@ -21,8 +21,8 @@ Release schedule
 :2022-05-02: First ansible-core release candidate.
 :2022-05-03: Ansible-6.0.0 alpha2.
 :2022-05-11: Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline.
+:2022-05-16: Ansible-core-2.13 released.
 :2022-05-17: Ansible-6.0.0 alpha3.
-:2022-05-23: Ansible-core-2.13 released.
 :2022-05-23: Last day for collections to make backwards incompatible releases that will be accepted into Ansible-6. This includes adding new collections to Ansible 6.0.0; from now on new collections have to wait for 6.1.0 or later.
 :2022-05-24: Create the ansible-build-data directory and files for Ansible-7.
 :2022-05-24: Ansible-6.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs).
diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_13.rst b/docs/docsite/rst/roadmap/ROADMAP_2_13.rst
index 1b46af68cc..00b994a570 100644
--- a/docs/docsite/rst/roadmap/ROADMAP_2_13.rst
+++ b/docs/docsite/rst/roadmap/ROADMAP_2_13.rst
@@ -37,9 +37,8 @@ Release Phase
 - 2022-04-25 Beta 2 (if necessary)
 
 - 2022-05-02 Release Candidate 1
-- 2022-05-16 Release Candidate 2 (if necessary)
 
-- 2022-05-23 Release
+- 2022-05-16 Release
 
 Release Manager
 ===============
diff --git a/docs/docsite/rst/shared_snippets/basic_concepts.txt b/docs/docsite/rst/shared_snippets/basic_concepts.txt
index 684340e5a4..d4154f6eaa 100644
--- a/docs/docsite/rst/shared_snippets/basic_concepts.txt
+++ b/docs/docsite/rst/shared_snippets/basic_concepts.txt
@@ -1,34 +1,69 @@
 Control node
 ============
+The machine from which you run the Ansible CLI tools (``ansible-playbook`` , ``ansible``, ``ansible-vault`` and others).
+You can use any computer that meets the software requirements as a control node - laptops, shared desktops, and servers can all run Ansible.
+Multiple control nodes are possible, but Ansible itself does not coordinate across them, see ``AAP`` for such features.
 
-Any machine with Ansible installed. You can run Ansible commands and playbooks by invoking the ``ansible`` or ``ansible-playbook`` command from any control node. You can use any computer that has a Python installation as a control node - laptops, shared desktops, and servers can all run Ansible. However, you cannot use a Windows machine as a control node. You can have multiple control nodes.
 
 Managed nodes
 =============
+Also referred to as 'hosts', these are the target devices (servers, network appliances or any computer) you aim to manage with Ansible.
+Ansible is not normally installed on managed nodes, unless you are using ``ansible-pull``, but this is rare and not the recommended setup.
 
-The network devices (and/or servers) you manage with Ansible. Managed nodes are also sometimes called "hosts". Ansible is not installed on managed nodes.
 
 Inventory
 =========
+A list of managed nodes provided by one or more 'inventory sources'. Your inventory can specify information specific to each node, like IP address.
+It is also used for assigning groups, that both allow for node selection in the Play and bulk variable assignment.
+To learn more about inventory, see :ref:`the Working with Inventory<intro_inventory>` section. Sometimes an inventory source file is also referred to as a 'hostfile'.
 
-A list of managed nodes. An inventory file is also sometimes called a "hostfile". Your inventory can specify information like IP address for each managed node. An inventory can also organize managed nodes, creating and nesting groups for easier scaling. To learn more about inventory, see :ref:`the Working with Inventory<intro_inventory>` section.
 
-Collections
-===========
+Playbooks
+=========
+They contain Plays (which are the basic unit of Ansible execution). this is both an 'execution concept' and how we describe the files on which ``ansible-playbook`` operates on.
+Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`.
+
+Plays
+-----
+The main context for Ansible execution, this playbook object maps managed nodes (hosts) to tasks.
+The Play contains variables, roles and an ordered lists of tasks and can be run repeatedly.
+It basically consists of an implicit loop over the mapped hosts and tasks and defines how to iterate over them.
+
+Roles
+.....
+A limited distribution of reusable ansible content (tasks, handlers, variables, plugins, templates and files) for use inside of a Play.
+To use any Role resource, the Role itself must be imported into the Play.
+
+Tasks
+.....
+The definition of an 'action' to be applied to the managed host. Tasks must always be contained in a Play, directly or indirectly (Role, or imported/included task list file).
+You can execute a single task once with an ad hoc command ``ansible`` or ``ansible-console`` (both create a virtual Play).
+
+Handlers
+........
+Special form of a Task, that only execute when notified by a previous task which resulted in a 'changed' status.
 
-Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_. To learn more about collections, see :ref:`collections`.
 
 Modules
 =======
+The code or binaries that Ansible copies and executes on each managed node (when needed) to accomplish the action defined in each Task.
+Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device.
+You can invoke a single module with a task, or invoke several different modules in a playbook.
+Ansible modules are grouped in collections. For an idea of how many collections Ansible includes, see the :ref:`list_of_collections`.
 
-The units of code Ansible executes. Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device. You can invoke a single module with a task, or invoke several different modules in a playbook. Starting in Ansible 2.10, modules are grouped in collections. For an idea of how many collections Ansible includes, take a look at the :ref:`list_of_collections`.
 
-Tasks
-=====
+Plugins
+=======
+Pieces of code that expand Ansible's core capabilities, they can control how you connect to a managed node (connection plugins),
+manipulate data (filter plugins) and even control what is displayed in the console (callback plugins).
+See :ref:`working_with_plugins` for details.
 
-The units of action in Ansible. You can execute a single task once with an ad hoc command.
 
-Playbooks
-=========
+Collections
+===========
+Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_. To learn more about collections, see :ref:`collections`. Collection resources can be used independently and discretely from each other.
+
 
-Ordered lists of tasks, saved so you can run those tasks in that order repeatedly. Playbooks can include variables as well as tasks. Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`.
+AAP
+===
+Short for 'Ansible Automation Platform'. This is a product that includes enterprise level features and integrates many tools of the Ansible ecosystem: ansible-core, awx, galaxyNG, and so on.
diff --git a/docs/docsite/rst/user_guide/quickstart.rst b/docs/docsite/rst/user_guide/quickstart.rst
index 7e97d9ab82..3b56c877fd 100644
--- a/docs/docsite/rst/user_guide/quickstart.rst
+++ b/docs/docsite/rst/user_guide/quickstart.rst
@@ -5,7 +5,7 @@ Ansible Quickstart Guide
 
 We've recorded a short video that introduces Ansible.
 
-The `quickstart video <https://www.ansible.com/resources/videos/quick-start-video>`_ is about 13 minutes long and gives you a high level
+The `quickstart video <https://www.ansible.com/resources/get-started?hsLang=en-us>`_ is about 13 minutes long and gives you a high level
 introduction to Ansible -- what it does and how to use it. We'll also tell you about other products in the Ansible ecosystem.
 
 Enjoy, and be sure to visit the rest of the documentation to learn more.