Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package ansible-documentation for
openSUSE:Factory checked in at 2026-11-06 19:55:24
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/ansible-documentation (Old)
and /work/SRC/openSUSE:Factory/.ansible-documentation.new.3759290 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "ansible-documentation"
Fri Nov 6 19:55:24 2026 rev:44 rq:1395736 version:2.21.6
Changes:
--------
---
/work/SRC/openSUSE:Factory/ansible-documentation/ansible-documentation.changes
2026-10-08 13:28:44.804204256 +0200
+++
/work/SRC/openSUSE:Factory/.ansible-documentation.new.3759290/ansible-documentation.changes
2026-11-06 20:00:39.056898144 +0100
@@ -1,0 +2,25 @@
+Fri Nov 06 08:48:18 UTC 2026 - Johannes Kastl
<[email protected]>
+
+- Update to version 2.21.6:
+ * [PR #4126/e2917a4f backport][stable-2.21] Reflect that
+ synchronous DaWGs meetings don't happen anymore (#4129)
+ * ci: refresh dev dependencies (#4115)
+ * documentation_contributions.rst: add link to open issues on
+ ansible-documentatiojn repo (#4121) (#4123)
+ * Update actions. (#4102)
+ * [Steering Committee vote is NEEDED before merge] Update
+ inclusion process with SC-selected model (#4065) (#4108)
+ * Suggest short_description at the top of DOCUMENTATION (#4079)
+ (#4097)
+ * ci: refresh dev dependencies (#4088)
+ * [stable-2.21] ci: refresh docs build dependencies (#4072)
+ * ci: refresh dev dependencies (#4084)
+ * Fix YAML syntax in playbook example (#4009) (#4069)
+ * Merge pull request #3999 from bcoca/passlib_changes (#4035)
+ * ci: refresh dev dependencies (#4051)
+ * Enhance 2.16 porting guide with warnings backports (#4036)
+ (#4045)
+ * Merge pull request #4030 from Shrews/warning-backports
+ * Add the Ansible community 14.5.0 porting guide (#4031) (#4033)
+
+-------------------------------------------------------------------
Old:
----
ansible-documentation-2.21.5.obscpio
New:
----
ansible-documentation-2.21.6.obscpio
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ ansible-documentation.spec ++++++
--- /var/tmp/diff_new_pack.qpiLX8/_old 2026-11-06 20:00:42.206029969 +0100
+++ /var/tmp/diff_new_pack.qpiLX8/_new 2026-11-06 20:00:42.208030053 +0100
@@ -17,7 +17,7 @@
Name: ansible-documentation
-Version: 2.21.5
+Version: 2.21.6
Release: 0
Summary: Ansible community documentation and example files
License: GPL-3.0-only
++++++ _service ++++++
--- /var/tmp/diff_new_pack.qpiLX8/_old 2026-11-06 20:00:42.295033695 +0100
+++ /var/tmp/diff_new_pack.qpiLX8/_new 2026-11-06 20:00:42.303034030 +0100
@@ -3,7 +3,7 @@
<param
name="url">https://github.com/ansible/ansible-documentation.git</param>
<param name="scm">git</param>
<param name="exclude">.git</param>
- <param name="revision">refs/tags/v2.21.5</param>
+ <param name="revision">refs/tags/v2.21.6</param>
<param name="versionformat">@PARENT_TAG@</param>
<param name="versionrewrite-pattern">v(.*)</param>
<param name="changesgenerate">enable</param>
++++++ _servicedata ++++++
--- /var/tmp/diff_new_pack.qpiLX8/_old 2026-11-06 20:00:42.347035872 +0100
+++ /var/tmp/diff_new_pack.qpiLX8/_new 2026-11-06 20:00:42.355036207 +0100
@@ -3,6 +3,6 @@
<param
name="url">https://github.com/ansible/ansible-documentation</param>
<param
name="changesrevision">24dc86db4bb88b47a8f4f12e35f32508510ce69d</param></service><service
name="tar_scm">
<param
name="url">https://github.com/ansible/ansible-documentation.git</param>
- <param
name="changesrevision">1a3791f380e9380efaa549df2e7d3e78cd8d9501</param></service></servicedata>
+ <param
name="changesrevision">386eb8455b5dc5e42711a87417c06fcd17ef23c4</param></service></servicedata>
(No newline at EOF)
++++++ ansible-documentation-2.21.5.obscpio ->
ansible-documentation-2.21.6.obscpio ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/ansible-documentation-2.21.5/MAINTAINERS.md
new/ansible-documentation-2.21.6/MAINTAINERS.md
--- old/ansible-documentation-2.21.5/MAINTAINERS.md 2026-10-05
09:23:09.000000000 +0200
+++ new/ansible-documentation-2.21.6/MAINTAINERS.md 2026-11-02
13:43:20.000000000 +0100
@@ -2,9 +2,7 @@
Find details about maintaining the `ansible-documentation` repository.
Note that maintainers have privileged access to the repository to perform
special functions such as branching for new versions and preparing Ansible
documentation for publishing.
-If you're interested in becoming a maintainer, or want to get in touch with
us, please join us on Matrix at
[#docs:ansible.im](https://matrix.to/#/#docs:ansible.im).
-We have weekly meetings on Matrix every Tuesday.
-See [the Ansible calendar](https://forum.ansible.com/upcoming-events) for
meeting details.
+If you're interested in becoming a maintainer, or want to get in touch with
us, please join us on [Ansible
Forum](https://forum.ansible.com/tag/documentation/7) and Matrix at
[#docs:ansible.im](https://matrix.to/#/#docs:ansible.im).
## Requesting review from legal
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/community/collection_contributors/collection_package_removal.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/community/collection_contributors/collection_package_removal.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/community/collection_contributors/collection_package_removal.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/community/collection_contributors/collection_package_removal.rst
2026-11-02 13:43:20.000000000 +0100
@@ -115,7 +115,7 @@
Conditions
~~~~~~~~~~
-Conditions under which the collections can be re-included in the Ansible
package without going through the `full inclusion process
<https://github.com/ansible-collections/ansible-inclusion/>`_:
+Conditions under which the collections can be re-included in the Ansible
package without going through the :ref:`full inclusion
process<steering_inclusion>`:
#. The issues have to be fixed and a new release has to be made before the
Ansible X+2 feature freeze.
#. Someone has to promise to maintain the collection and prevent a similar
situation at least for some time.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/community/collection_contributors/collection_requirements.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/community/collection_contributors/collection_requirements.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/community/collection_contributors/collection_requirements.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/community/collection_contributors/collection_requirements.rst
2026-11-02 13:43:20.000000000 +0100
@@ -16,11 +16,7 @@
Overview
========
-This document describes the requirements for maintainers of Ansible community
collections included in the Ansible community package. All inclusion candidates
and already included collections must meet the criteria marked with ``MUST`` in
this document.
-
-You can also find these requirements on the `Collection inclusion criteria
checklist
<https://github.com/ansible-collections/overview/blob/main/collection_checklist.md>`_.
-
-Every rejected candidate will get feedback from the
:ref:`community_steering_committee` based on a decision made in a dedicated
:ref:`community topic<creating_community_topic>`.
+This document describes the requirements for Ansible community collections
included in the Ansible community package. All included collections must
satisfy the requirements marked with ``MUST`` in this document. Collections not
satisfying these requirements may be subject to the :ref:`removal_from_ansible`.
Feedback and communications
==============================
@@ -568,8 +564,8 @@
Other requirements
===================
-* After content is moved out of another currently included collection such as
``community.general`` or ``community.network`` OR a new collection satisfies
all the requirements, see `Adding a new collection
<https://github.com/ansible-community/ansible-build-data/#adding-a-new-collection>`_
in the `ansible-build-data repository
<https://github.com/ansible-community/ansible-build-data/>`_'s README.
-* :ref:`The Steering Committee <steering_responsibilities>` can reject a
collection inclusion request or exclude a collection from the Ansible package
even if the collection satisfies the requirements listed in this document. See
the :ref:`Collection inclusion request workflow<steering_inclusion>` for
details.
+* After content is moved out of another currently included collection such as
``community.general``, see `Adding a new collection
<https://github.com/ansible-community/ansible-build-data/#adding-a-new-collection>`_
in the `ansible-build-data repository
<https://github.com/ansible-community/ansible-build-data/>`_'s README.
+* :ref:`The Steering Committee <steering_responsibilities>` can exclude a
collection from the Ansible package even if the collection satisfies the
requirements listed in this document. See the :ref:`Collection inclusion
criteria and process<steering_inclusion>` for details.
.. seealso::
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/community/documentation_contributions.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/community/documentation_contributions.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/community/documentation_contributions.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/community/documentation_contributions.rst
2026-11-02 13:43:20.000000000 +0100
@@ -40,6 +40,7 @@
Review or solve open documentation issues for:
+- `Ansible `documentation
<https://github.com/ansible/ansible-documentation/issues>`_
- `Ansible projects
<https://github.com/search?q=user%3Aansible+user%3Aansible-community+label%3Adocs+state%3Aopen+type%3Aissue&type=Issues>`_
- `Ansible collections
<https://github.com/search?q=user%3Aansible-collections+label%3Adocs+state%3Aopen+type%3Aissue&type=Issues>`_
@@ -232,7 +233,7 @@
Joining the documentation working group
=======================================
-The Documentation Working Group (DaWGs) meets weekly on Tuesdays in the
`docs:ansible.im chat room <https://matrix.to/#/#docs:ansible.im>`_ on
:ref:`Matrix<communication_irc>`. For more information, including links to our
agenda, visit our `forum group <https://forum.ansible.com/g/Docs>`_.
+The Documentation Working Group (DaWGs) discusses Ansible documentation on the
`Ansible Forum <https://forum.ansible.com>`_ in topics labeled with
`documentation tag <https://forum.ansible.com/tag/documentation/7>`_ and in the
`docs:ansible.im chat room <https://matrix.to/#/#docs:ansible.im>`_ on
:ref:`Matrix<communication_irc>`.
.. seealso::
:ref:`More about testing module documentation
<testing_module_documentation>`
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/community/maintainers_workflow.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/community/maintainers_workflow.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/community/maintainers_workflow.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/community/maintainers_workflow.rst
2026-11-02 13:43:20.000000000 +0100
@@ -46,7 +46,7 @@
Including a collection in Ansible
-----------------------------------
-To include a collection in the Ansible community package, maintainers create a
discussion in the `ansible-collections/ansible-inclusion repository
<https://github.com/ansible-collections/ansible-inclusion>`_. See the
`submission process
<https://github.com/ansible-collections/ansible-inclusion/blob/main/README.md>`_
and the :ref:`Ansible community package collections requirements
<collections_requirements>` for details.
+The :ref:`Steering Committee <steering_responsibilities>` selects collections
for inclusion in the Ansible community package. See the :ref:`collection
inclusion criteria and process<steering_inclusion>` and the :ref:`Ansible
community package collections requirements <collections_requirements>` for
details.
Stepping down as a collection maintainer
===========================================
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/community/steering/community_steering_committee.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/community/steering/community_steering_committee.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/community/steering/community_steering_committee.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/community/steering/community_steering_committee.rst
2026-11-02 13:43:20.000000000 +0100
@@ -9,7 +9,7 @@
Steering Committee mission and responsibilities
===============================================
-The Steering Committee mission is to provide continuity, guidance, and
suggestions to the Ansible community to ensure the delivery and high quality of
the Ansible package. In addition, the committee helps decide the technical
direction of the Ansible project. It is responsible for approving new proposals
and policies in the community, package, and community collections world, new
community collection-inclusion requests, and other technical aspects regarding
inclusion and packaging.
+The Steering Committee mission is to provide continuity, guidance, and
suggestions to the Ansible community to ensure the delivery and high quality of
the Ansible package. In addition, the committee helps decide the technical
direction of the Ansible project. It is responsible for approving new proposals
and policies in the community, package, and community collections world, and
other technical aspects regarding inclusion and packaging.
The Committee should reflect the scope and breadth of the Ansible community.
Steering Committee responsibilities
@@ -21,7 +21,7 @@
* Votes on approval changes to established policies and procedures.
* Reviews community collections for compliance with the policies.
* Helps create and define roadmaps for our deliverables such as the
``ansible`` package, major community collections, and documentation.
-* Reviews community collections submitted for inclusion in the Ansible package
and decides whether to include them or not.
+* Selects collections for inclusion in the Ansible package and maintains the
package composition.
* Review other proposals of importance that need the Committee's attention and
provide feedback.
.. _steering_members:
@@ -74,8 +74,8 @@
.. _creating_community_topic:
-Creating new policy proposals & inclusion requests
-----------------------------------------------------
+Creating new policy proposals
+-----------------------------
The Committee uses the `Ansible Forum <https://forum.ansible.com/>`_ to
asynchronously discuss with the Community and vote on the proposals in
corresponding `community topics
<https://forum.ansible.com/tags/c/project/7/community-wg>`_.
@@ -92,15 +92,10 @@
#. Submit a new pull request against the document by clicking the ``Edit``
button on its web page.
#. Create a `community topic
<https://forum.ansible.com/new-topic?category=project&tags=community-wg>`_
containing the rationale for the proposed changes.
-To submit new collections for inclusion into the Ansible package:
-
-* Submit the new collection inclusion requests through a new discussion in the
`ansible-inclusion
<https://github.com/ansible-collections/ansible-inclusion/discussions/new>`_
repository.
-
Depending on a topic you want to discuss with the Community and the Committee,
as you prepare your proposal, please consider the requirements established by:
* :ref:`code_of_conduct`.
* :ref:`collections_requirements`.
-* `Ansible Collection Inclusion Checklist
<https://github.com/ansible-collections/ansible-inclusion/blob/main/collection_checklist.md>`_.
* :ref:`removal_from_ansible`.
.. _community_topics_sc:
@@ -140,40 +135,24 @@
.. _steering_inclusion:
-Collection inclusion requests workflow
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-When reviewing community collection `inclusion requests
<https://github.com/ansible-collections/ansible-inclusion/discussions>`_, the
Committee members check if a collection adheres to the
:ref:`collections_requirements`.
-
-.. note::
-
- The Steering Committee can reject a collection inclusion request or exclude
a collection from the Ansible package even when the collection satisfies the
requirements if the Steering Committee agrees that presence of the collection
will significantly deteriorate the Ansible package user experience or the
package build process. In case of rejection/removal, the collection maintainers
receive comprehensive feedback from the Committee explaining the reasons of
starting the process. In case the reasons are fixable, the feedback will
contain information what the maintainers need to change.
-
-#. A Committee member who conducts the inclusion review copies the `Ansible
community collection checklist
<https://github.com/ansible-collections/ansible-inclusion/blob/main/collection_checklist.md>`_
into a corresponding `discussion
<https://github.com/ansible-collections/ansible-inclusion/discussions>`_.
-
-#. In the course of the review, the Committee member marks items as completed
or leaves a comment saying whether the reviewer expects an issue to be
addressed or whether it is optional (for example, it could be **MUST FIX:**
<what> or **SHOULD FIX:** <what> under an item).
-
-#. For a collection to be included in the Ansible community package, the
collection:
-
- * MUST be reviewed and approved as compliant with the requirements by at
least two Steering Committee members.
-
- * At least one of the reviews checks compliance with the entire checklist.
- * All subsequent reviews can focus only on compliance with documentation
and development conventions.
+Collection inclusion criteria and process
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- * Reviewers must not be involved significantly in development of the
collection. They MUST declare any potential conflict of interest (for example,
being friends/relatives/coworkers of the maintainers/authors, being users of
the collection, or having contributed to that collection recently or in the
past).
+Inclusion of new collections is exceptional. The Committee may consider a
collection for inclusion when it meets the following criteria. These criteria
are not exhaustive; they serve as guidelines for the Committee's judgment.
-#. After the collection gets two Committee member approvals, a Committee
member creates a `community topic
<https://forum.ansible.com/new-topic?category=project&tags=community-wg>`_
linked to the corresponding inclusion request. The issue's description says
that the collection has been approved by the Committee and establishes a date
(a week by default) when the inclusion decision will be considered made.
+* The collection automates infrastructure components, tools, or services that
are essential and present in the majority of environments (for example,
operating systems, DNS, containerization, cryptography, widely-used DevOps
tools).
+* The collection is non-vendor-specific. An exception can be made for
platforms so widely adopted that they are considered essential infrastructure
(for example, major cloud providers).
+* The collection's scope is broadly applicable across industries and use cases
rather than limited to a specific domain or niche.
+* The collection satisfies the :ref:`collections_requirements`.
- * The inclusion automatically gets suspended if the Committee members raise
concerns or start another inclusion review within this time period.
- * When there are no more objections or ongoing inclusion reviews, the
inclusion date gets prolonged for another week.
+Any community member may nominate a collection for inclusion by creating a
forum topic under the `Ansible Community Package Inclusion category
<https://forum.ansible.com/c/project/ansible-community-package-inclusion/52>`_.
The community then can discuss the nomination. If a member of the Steering
Committee thinks that this discussion shows support for adding the collection
to the package, the member initiates a vote on its inclusion following the
:ref:`community topics workflow<community_topics_sc>`.
-#. If the inclusion has not been suspended by the established date, the
inclusion request is considered successfully resolved. In this case, a
Committee member:
+If the Committee approves the inclusion, a Committee member:
- #. Declares the decision in the topic and in the inclusion request.
- #. Moves the request to the ``Resolved reviews`` category.
- #. Adds the collection to the ``ansible.in`` file in a corresponding
directory of the `ansible-build-data repository
<https://github.com/ansible-community/ansible-build-data>`_.
- #. Announces the inclusion through the `Bullhorn newsletter
<https://forum.ansible.com/c/news/bullhorn/17>`_.
- #. Closes the topic.
+#. Declares the decision in the community topic.
+#. Follows `the technical process in ansible-build-data
<(https://github.com/ansible-community/ansible-build-data/tree/main#adding-a-new-collection>`_
to actually add the collection.
+#. Announces the inclusion through the `Bullhorn newsletter
<https://forum.ansible.com/c/news/bullhorn/17>`_.
+#. Closes the topic.
Collection exclusion workflow
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/dev_guide/developing_collections_path.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/dev_guide/developing_collections_path.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/dev_guide/developing_collections_path.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/dev_guide/developing_collections_path.rst
2026-11-02 13:43:20.000000000 +0100
@@ -133,8 +133,8 @@
Make your collection a part of Ansible community package
========================================================
-Make your collection satisfy the :ref:`Ansible community package collections
requirements<collections_requirements>` and submit it for inclusion.
-See the `inclusion process description
<https://github.com/ansible-collections/ansible-inclusion/blob/main/README.md>`_
to learn how.
+Make your collection satisfy the :ref:`Ansible community package collections
requirements<collections_requirements>`.
+The :ref:`Steering Committee <steering_responsibilities>` selects collections
for inclusion. See the :ref:`collection inclusion criteria and
process<steering_inclusion>` for details.
Maintain
========
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/dev_guide/developing_modules_documenting.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/dev_guide/developing_modules_documenting.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/dev_guide/developing_modules_documenting.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/dev_guide/developing_modules_documenting.rst
2026-11-02 13:43:20.000000000 +0100
@@ -121,6 +121,9 @@
so it needs enough detail to explain the module's purpose without the
context of the directory structure in which it lives.
* Unlike ``description:``, ``short_description`` MUST NOT have a trailing
period/full stop.
* You can use :ref:`Ansible markup <ansible_markup>` in this field.
+ * Put ``short_description`` at the top of the ``DOCUMENTATION`` block,
before ``options``.
+ ``ansible-doc -l`` does not parse the YAML; it uses the first
``short_description:`` line it finds,
+ so an option with the same name that comes earlier would be used instead.
:description:
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/playbook_guide/playbooks_intro.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/playbook_guide/playbooks_intro.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/playbook_guide/playbooks_intro.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/playbook_guide/playbooks_intro.rst
2026-11-02 13:43:20.000000000 +0100
@@ -45,30 +45,30 @@
remote_user: root
tasks:
- - name: Ensure apache is at the latest version
- ansible.builtin.yum:
- name: httpd
- state: latest
-
- - name: Write the apache config file
- ansible.builtin.template:
- src: /srv/httpd.j2
- dest: /etc/httpd.conf
+ - name: Ensure apache is at the latest version
+ ansible.builtin.yum:
+ name: httpd
+ state: latest
+
+ - name: Write the apache config file
+ ansible.builtin.template:
+ src: /srv/httpd.j2
+ dest: /etc/httpd.conf
- name: Update db servers
hosts: databases
remote_user: root
tasks:
- - name: Ensure postgresql is at the latest version
- ansible.builtin.yum:
- name: postgresql
- state: latest
-
- - name: Ensure that postgresql is started
- ansible.builtin.service:
- name: postgresql
- state: started
+ - name: Ensure postgresql is at the latest version
+ ansible.builtin.yum:
+ name: postgresql
+ state: latest
+
+ - name: Ensure that postgresql is started
+ ansible.builtin.service:
+ name: postgresql
+ state: started
Your playbook can include more than just a hosts line and tasks. For example,
the playbook above sets a ``remote_user`` for each play. The ``remote_user`` is
the user account for the SSH connection. You can add other
:ref:`playbook_keywords` at the playbook, play, or task level to influence how
Ansible behaves. Playbook keywords can control the :ref:`connection plugin
<connection_plugins>`, whether to use :ref:`privilege escalation <become>`, how
to handle errors, and more. To support a variety of environments, you can set
many of these parameters as command-line flags in your Ansible configuration,
or in your inventory. Learning the :ref:`precedence rules
<general_precedence_rules>` for these sources of data helps you as you expand
your Ansible ecosystem.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/porting_guides/porting_guide_14.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/porting_guides/porting_guide_14.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/porting_guides/porting_guide_14.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/porting_guides/porting_guide_14.rst
2026-11-02 13:43:20.000000000 +0100
@@ -101,6 +101,53 @@
No notable changes
+Porting Guide for v14.5.0
+=========================
+
+Deprecated Features
+-------------------
+
+- The cisco.ucs collection will be removed from Ansible 16.
+ There is no active development happening on the collection. This has moved
to cisco.intersight which is also part of the ACP.
+ See `the removal discussion for details
<https://forum.ansible.com/t/46220>`__.
+ After removal, users can still install this collection with ``ansible-galaxy
collection install cisco.ucs``.
+
+community.aws
+^^^^^^^^^^^^^
+
+- inspector_target - The module has been deprecated as Amazon has retired the
``Amazon Inspector Classic`` service on May 20, 2026 (Complete End of Life),
revoking access to its console, APIs, and associated resources. The module will
be removed in version 12.0.0
(https://github.com/ansible-collections/community.aws/pull/2485).
+
+community.vmware
+^^^^^^^^^^^^^^^^
+
+- module_utils.vmware - The ``ansible_date_time_facts`` funtion is deprecated
and will be removed in community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2607).
+- module_utils.vmware_rest_client - The ``VmwareRestClient.get_tag_by_name``
method is deprecated and will be removed in community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2607).
+- module_utils.vmware_rest_client - The
``VmwareRestClient.get_tags_for_hostsystem`` method is deprecated and will be
removed in community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2607).
+- plugins.module_utils.vmware - The function
``find_host_by_cluster_datacenter`` is deprecated and will be removed in
community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware - The function ``vmware_argument_spec`` is
deprecated and will be removed in community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware - The method
``PyVmomi.get_all_hosts_by_cluster`` is deprecated and will be removed in
community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware - The method ``PyVmomi.get_folder_path`` is
deprecated and will be removed in community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware - The method
``PyVmomi.vcenter_version_at_least`` is deprecated and will be removed in
community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware_rest_client - The method
``VMwareRestClient.get_cluster_by_name`` is deprecated and will be removed in
community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware_rest_client - The method
``VMwareRestClient.get_datacenter_by_name`` is deprecated and will be removed
in community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware_rest_client - The method
``VMwareRestClient.get_datastore_by_name`` is deprecated and will be removed in
community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware_rest_client - The method
``VMwareRestClient.get_host_by_name`` is deprecated and will be removed in
community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware_rest_client - The method
``VMwareRestClient.get_library_item_by_name`` is deprecated and will be removed
in community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware_rest_client - The method
``VMwareRestClient.get_library_item_from_content_library_name`` is deprecated
and will be removed in community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware_rest_client - The method
``VMwareRestClient.get_resource_pool_by_name`` is deprecated and will be
removed in community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware_rest_client - The method
``VMwareRestClient.get_tags_for_cluster`` is deprecated and will be removed in
community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+- plugins.module_utils.vmware_rest_client - The method
``VMwareRestClient.vmware_client_argument_spec`` is deprecated and will be
removed in community.vmware 8.0.0
(https://github.com/ansible-collections/community.vmware/pull/2599).
+
+kubernetes.core
+^^^^^^^^^^^^^^^
+
+- Ansible Turbo mode (``ENABLE_TURBO_MODE``) has been deprecated and will be
removed in release 8.0.0, as it depends on the ``cloud.common`` collection,
which is being retired
(https://github.com/ansible-collections/kubernetes.core/pull/1242).
+- helm - the ``status.values`` return value has been deprecated and will be
removed in version 8.0.0. Use ``status.release_values`` instead
(https://github.com/ansible-collections/kubernetes.core/issues/1239).
+- helm - the ``wait_timeout`` parameter has been deprecated and will be
removed in version 7.0.0. Use ``timeout`` instead
(https://github.com/ansible-collections/kubernetes.core/issues/1239).
+- helm_info - the ``status.values`` return value has been deprecated and will
be removed in version 8.0.0. Use ``status.release_values`` instead
(https://github.com/ansible-collections/kubernetes.core/issues/1239).
+- k8s_exec - the ``return_code`` return value has been deprecated and will be
removed in version 7.0.0. Use ``rc`` instead
(https://github.com/ansible-collections/kubernetes.core/issues/1239).
+- k8s_service - the ``merge_type=json`` option has been deprecated and will be
removed in version 7.0.0. Use ``kubernetes.core.k8s_json_patch`` module instead
(https://github.com/ansible-collections/kubernetes.core/issues/1239).
+
Porting Guide for v14.4.0
=========================
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/porting_guides/porting_guide_core_2.16.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/porting_guides/porting_guide_core_2.16.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/porting_guides/porting_guide_core_2.16.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/porting_guides/porting_guide_core_2.16.rst
2026-11-02 13:43:20.000000000 +0100
@@ -51,6 +51,333 @@
Deprecated
==========
+``ansible-core`` 2.16.20 backports several warnings from versions 2.19 and
later, most of them deprecation warnings.
+These warnings give you advance notice of upcoming changes if you plan to
upgrade across several releases at once.
+The following sections describe each warning and how to resolve it. Except
where noted, you can disable these
+warnings by setting ``deprecation_warnings=False`` in ``ansible.cfg``.
+
+.. DWCODE: invalid_inventory_name
+
+Invalid inventory variables
+---------------------------
+
+Setting Ansible inventory variables with invalid names is deprecated.
Variables must start with a letter
+or underscore character, and contain only letters, numbers and underscores.
Variable names must also not
+be one of the following Jinja keywords: ``true``, ``True``, ``false``,
``False``, ``none``, ``None``, ``not``.
+
+Example
+^^^^^^^
+
+An example inventory with an invalid value:
+
+.. code-block:: text
+
+ localhost ansible_connection=local true=123
+
+will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Accepting inventory variable with invalid name
'true'. Variable names must be strings
+ starting with a letter or underscore character, and contain only letters,
numbers and underscores. This feature
+ will be removed in version 2.23. Deprecation warnings can be disabled by
setting deprecation_warnings=False in
+ ansible.cfg.
+
+This can be resolved by renaming the variable to match the requirements.
+
+.. DWCODE: task_args_empty
+
+Empty ``args`` keyword
+----------------------
+
+Specifying the task ``args`` keyword without a value is deprecated.
+
+Example
+^^^^^^^
+
+The example task below uses an empty ``args``:
+
+.. code-block:: yaml
+
+ - name: Print a message
+ ansible.builtin.debug:
+ msg: "Hello, World"
+ args:
+
+The above task will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Ignoring empty task `args` keyword. A mapping or
template which resolves to a mapping is
+ required. This feature will be removed in version 2.23. Deprecation
warnings can be disabled by setting
+ deprecation_warnings=False in ansible.cfg.
+
+This can be resolved by ensuring that ``args`` is never supplied an empty
value.
+
+.. DWCODE: task_action_mapping
+
+Using a mapping for ``action``
+------------------------------
+
+Using a mapping for ``action`` is deprecated. Use a string value for
``action``.
+
+Example
+^^^^^^^
+
+The example task below uses a mapping for the ``action`` keyword, specifying
the module to execute:
+
+.. code-block:: yaml
+
+ - name: Print a message
+ action:
+ module: "ansible.builtin.debug"
+ args:
+ msg: "Hello World!"
+
+The above task will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Using a mapping for `action` is deprecated. Use a
string value for `action`. This
+ feature will be removed in version 2.23. Deprecation warnings can be
disabled by setting
+ deprecation_warnings=False in ansible.cfg.
+
+This can be resolved by using a string for the ``action`` value, like so:
+
+.. code-block:: yaml
+
+ - name: Print a message
+ action: "ansible.builtin.debug"
+ args:
+ msg: "Hello World!"
+
+.. DWCODE: task_args_merge
+
+Task argument merging
+---------------------
+
+Using ``key=value`` style arguments and the task ``args`` keyword on the same
task is deprecated.
+
+Example
+^^^^^^^
+
+.. code-block:: yaml
+
+ - name: List home directories
+ ansible.builtin.find: paths="/home"
+ args:
+ file_type: "directory"
+
+The above task will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Merging legacy k=v args ('paths') into task args.
Include all task args in the task
+ `args` mapping. This feature will be removed in version 2.23. Deprecation
warnings can be disabled by setting
+ deprecation_warnings=False in ansible.cfg.
+
+One way to resolve this is by moving the key=value arguments into the ``args``
section. For example:
+
+.. code-block:: yaml
+
+ - name: List home directories
+ ansible.builtin.find:
+ args:
+ paths: "/home"
+ file_type: "directory"
+
+Alternatively, for this example, you could also provide the arguments with the
normal (and simpler) pattern:
+
+.. code-block:: yaml
+
+ - name: List home directories
+ ansible.builtin.find:
+ paths: "/home"
+ file_type: "directory"
+
+.. DWCODE: bool_filter_invalid_value
+
+Invalid ``bool`` filter values
+------------------------------
+
+Support for coercing unrecognized input values (including None) to a boolean
using the ``bool`` filter
+has been deprecated.
+
+Example
+^^^^^^^
+
+.. code-block:: yaml+jinja
+
+ - name: Print a message
+ ansible.builtin.debug:
+ msg: "{{ [] | bool }}"
+
+The above task will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: The `bool` filter coerced invalid value [] (list)
to False. This feature will be removed
+ in version 2.23. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.
+
+To resolve this, use an explicit predicate with a boolean result, such as ``|
length > 0`` or ``is truthy``.
+
+.. DWCODE: from_yaml_non_string
+.. DWCODE: from_yaml_all_non_string
+
+Filters ``from_yaml`` and ``from_yaml_all``
+-------------------------------------------
+
+Using the ``from_yaml`` and ``from_yaml_all`` filters with non-string data has
been deprecated.
+
+Example
+^^^^^^^
+
+.. code-block:: yaml+jinja
+
+ - name: Parse a list
+ ansible.builtin.debug:
+ msg: "{{ [] | from_yaml }}"
+
+ - name: Parse a mapping
+ ansible.builtin.debug:
+ msg: "{{ {} | from_yaml_all }}"
+
+The above tasks will produce the following warnings, respectively:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: The from_yaml filter ignored non-string input of
type <class 'list'>. This feature will be
+ removed in version 2.23. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.
+
+ [DEPRECATION WARNING]: The from_yaml_all filter ignored non-string input
of type <class 'dict'>. This feature will be
+ removed in version 2.23. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.
+
+To resolve these, make sure your inputs are of a string type.
+
+.. DWCODE: templar_available_variables
+
+Accessing ``Templar._available_variables``
+------------------------------------------
+
+Direct access to the ``_available_variables`` internal attribute of the
``Templar`` class is deprecated.
+
+Accessing that internal variable will result in the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Direct access to the `_available_variables`
internal attribute is deprecated. This feature
+ will be removed from ansible-core version 2.23. Use `available_variables`
instead.
+
+To resolve this, use the ``Templar.available_variables`` attribute instead.
+
+.. DWCODE: templar_loader
+
+Accessing ``Templar._loader``
+-----------------------------
+
+Direct access to the ``_loader`` internal attribute of the ``Templar`` class
is deprecated.
+
+Accessing that internal variable will result in the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Direct access to the `_loader` internal attribute
is deprecated. This feature will be
+ removed from ansible-core version 2.23. Use `copy_with_new_env` to create
a new instance.
+
+Use the ``Templar.copy_with_new_env()`` method if you only need a derived
``Templar`` instance. If you need the
+data loader itself, keep a reference to the ``DataLoader`` you created rather
than reading it back from the
+``Templar``, since the attribute it is stored in is internal and subject to
change.
+
+.. DWCODE: templar_environment
+
+Accessing ``Templar.environment``
+---------------------------------
+
+Direct access to the ``environment`` attribute of the ``Templar`` class is
deprecated.
+
+Accessing that internal variable will result in the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Direct access to the `environment` attribute is
deprecated. This feature will be
+ removed from ansible-core version 2.23. Consider using `copy_with_new_env`
or passing `overrides` to `template`.
+
+As suggested by the deprecation warning, use the
``Templar.copy_with_new_env()`` method to obtain a new
+``Templar`` instance, or use ``Templar.template()`` and set the ``overrides``
parameter.
+
+.. DWCODE: conditional_empty
+
+Empty conditional expressions
+-----------------------------
+
+Conditional expressions (such as ``when`` in playbook tasks or ``that`` in the
``assert`` action) which are a
+literal ``None`` or an empty string evaluate as True and will issue a
deprecation warning.
+
+Example
+^^^^^^^
+
+.. code-block:: yaml+jinja
+
+ - name: Print a message
+ ansible.builtin.debug:
+ msg: "test"
+ when: ""
+
+The above task will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Empty conditional expression was evaluated as True.
This feature will be removed in
+ version 2.23. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.
+
+Such expressions should be removed or corrected to always ensure a strictly
boolean (True or False) result.
+
+.. DWCODE: test_non_boolean
+
+Non-boolean test plugin results
+-------------------------------
+
+Test plugins which return a non-boolean result are deprecated; the result is
coerced to a boolean for now, but
+test plugins must have a boolean result in ansible-core 2.23 and later.
+
+Non-conforming test plugins will see a deprecation message like the following:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: The test plugin 'my_test_plugin' returned a
non-boolean result of type <class 'NoneType'>.
+ Test plugins must have a boolean result. This feature will be removed in
version 2.23. Deprecation warnings can be
+ disabled by setting deprecation_warnings=False in ansible.cfg.
+
+To resolve this, update the test plugin to return a boolean, for example by
wrapping the result in ``bool()``.
+Starting with ansible-core 2.23, a non-boolean result is an error rather than
a warning.
+
+.. DWCODE: unknown_type_encountered_handler
+
+Templating of unknown types
+---------------------------
+
+A warning is now emitted when a type unknown to the templating system is
encountered in a finalized template result,
+since such types are not guaranteed to behave correctly.
+
+Unlike the other warnings in this section, this is a general warning rather
than a deprecation warning. Nothing is
+being removed in 2.23, and setting ``deprecation_warnings=False`` in
``ansible.cfg`` does not suppress it.
+
+Pinpointing the location of the use of the unknown type is not possible unless
you are using ``ansible-core`` 2.19
+or higher, where the origin will be displayed along with the warning. This is
a best effort notification, giving the name
+of the type that is unknown to the templating system.
+
+Warnings of this type will look similar to the following:
+
+.. code-block:: text
+
+ [WARNING]: Encountered unknown type 'NotAVariableType' during template
operation. Use supported types to avoid
+ unexpected behavior. To troubleshoot further, please upgrade to Ansible
core 2.19 or later to find out more about
+ the origin of this type.
+
+Custom data types outside of Ansible will be unsupported. Normal Python data
types (for example: ``bool``,
+``bytes``, ``dict``, ``list``, etc) and many custom Ansible data types (for
example: ``AnsibleMapping``,
+``AnsibleSequence``, ``HostVars``, etc) are supported.
+
Modules
=======
@@ -84,4 +411,3 @@
Networking
==========
-
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/porting_guides/porting_guide_core_2.18.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/porting_guides/porting_guide_core_2.18.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/porting_guides/porting_guide_core_2.18.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/porting_guides/porting_guide_core_2.18.rst
2026-11-02 13:43:20.000000000 +0100
@@ -32,8 +32,332 @@
Deprecated
==========
-No notable changes
+``ansible-core`` 2.18.20 backports several warnings from versions 2.19 and
later, most of them deprecation warnings.
+These warnings give you advance notice of upcoming changes if you plan to
upgrade across several releases at once.
+The following sections describe each warning and how to resolve it. Except
where noted, you can disable these
+warnings by setting ``deprecation_warnings=False`` in ``ansible.cfg``.
+.. DWCODE: invalid_inventory_name
+
+Invalid inventory variables
+---------------------------
+
+Setting Ansible inventory variables with invalid names is deprecated.
Variables must start with a letter
+or underscore character, and contain only letters, numbers and underscores.
Variable names must also not
+be one of the following Jinja keywords: ``true``, ``True``, ``false``,
``False``, ``none``, ``None``, ``not``.
+
+Example
+^^^^^^^
+
+An example inventory with an invalid value:
+
+.. code-block:: text
+
+ localhost ansible_connection=local true=123
+
+will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Accepting inventory variable with invalid name
'true'. Variable names must be strings
+ starting with a letter or underscore character, and contain only letters,
numbers and underscores. This feature
+ will be removed in version 2.23. Deprecation warnings can be disabled by
setting deprecation_warnings=False in
+ ansible.cfg.
+
+This can be resolved by renaming the variable to match the requirements.
+
+.. DWCODE: task_args_empty
+
+Empty ``args`` keyword
+----------------------
+
+Specifying the task ``args`` keyword without a value is deprecated.
+
+Example
+^^^^^^^
+
+The example task below uses an empty ``args``:
+
+.. code-block:: yaml
+
+ - name: Print a message
+ ansible.builtin.debug:
+ msg: "Hello, World"
+ args:
+
+The above task will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Ignoring empty task `args` keyword. A mapping or
template which resolves to a mapping is
+ required. This feature will be removed in version 2.23. Deprecation
warnings can be disabled by setting
+ deprecation_warnings=False in ansible.cfg.
+
+This can be resolved by ensuring that ``args`` is never supplied an empty
value.
+
+.. DWCODE: task_action_mapping
+
+Using a mapping for ``action``
+------------------------------
+
+Using a mapping for ``action`` is deprecated. Use a string value for
``action``.
+
+Example
+^^^^^^^
+
+The example task below uses a mapping for the ``action`` keyword, specifying
the module to execute:
+
+.. code-block:: yaml
+
+ - name: Print a message
+ action:
+ module: "ansible.builtin.debug"
+ args:
+ msg: "Hello World!"
+
+The above task will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Using a mapping for `action` is deprecated. Use a
string value for `action`. This
+ feature will be removed in version 2.23. Deprecation warnings can be
disabled by setting
+ deprecation_warnings=False in ansible.cfg.
+
+This can be resolved by using a string for the ``action`` value, like so:
+
+.. code-block:: yaml
+
+ - name: Print a message
+ action: "ansible.builtin.debug"
+ args:
+ msg: "Hello World!"
+
+.. DWCODE: task_args_merge
+
+Task argument merging
+---------------------
+
+Using ``key=value`` style arguments and the task ``args`` keyword on the same
task is deprecated.
+
+Example
+^^^^^^^
+
+.. code-block:: yaml
+
+ - name: List home directories
+ ansible.builtin.find: paths="/home"
+ args:
+ file_type: "directory"
+
+The above task will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Merging legacy k=v args ('paths') into task args.
Include all task args in the task
+ `args` mapping. This feature will be removed in version 2.23. Deprecation
warnings can be disabled by setting
+ deprecation_warnings=False in ansible.cfg.
+
+One way to resolve this is by moving the key=value arguments into the ``args``
section. For example:
+
+.. code-block:: yaml
+
+ - name: List home directories
+ ansible.builtin.find:
+ args:
+ paths: "/home"
+ file_type: "directory"
+
+Alternatively, for this example, you could also provide the arguments with the
normal (and simpler) pattern:
+
+.. code-block:: yaml
+
+ - name: List home directories
+ ansible.builtin.find:
+ paths: "/home"
+ file_type: "directory"
+
+.. DWCODE: bool_filter_invalid_value
+
+Invalid ``bool`` filter values
+------------------------------
+
+Support for coercing unrecognized input values (including None) to a boolean
using the ``bool`` filter
+has been deprecated.
+
+Example
+^^^^^^^
+
+.. code-block:: yaml+jinja
+
+ - name: Print a message
+ ansible.builtin.debug:
+ msg: "{{ [] | bool }}"
+
+The above task will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: The `bool` filter coerced invalid value [] (list)
to False. This feature will be removed
+ in version 2.23. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.
+
+To resolve this, use an explicit predicate with a boolean result, such as ``|
length > 0`` or ``is truthy``.
+
+.. DWCODE: from_yaml_non_string
+.. DWCODE: from_yaml_all_non_string
+
+Filters ``from_yaml`` and ``from_yaml_all``
+-------------------------------------------
+
+Using the ``from_yaml`` and ``from_yaml_all`` filters with non-string data has
been deprecated.
+
+Example
+^^^^^^^
+
+.. code-block:: yaml+jinja
+
+ - name: Parse a list
+ ansible.builtin.debug:
+ msg: "{{ [] | from_yaml }}"
+
+ - name: Parse a mapping
+ ansible.builtin.debug:
+ msg: "{{ {} | from_yaml_all }}"
+
+The above tasks will produce the following warnings, respectively:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: The from_yaml filter ignored non-string input of
type <class 'list'>. This feature will be
+ removed in version 2.23. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.
+
+ [DEPRECATION WARNING]: The from_yaml_all filter ignored non-string input
of type <class 'dict'>. This feature will be
+ removed in version 2.23. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.
+
+To resolve these, make sure your inputs are of a string type.
+
+.. DWCODE: templar_available_variables
+
+Accessing ``Templar._available_variables``
+------------------------------------------
+
+Direct access to the ``_available_variables`` internal attribute of the
``Templar`` class is deprecated.
+
+Accessing that internal variable will result in the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Direct access to the `_available_variables`
internal attribute is deprecated. This feature
+ will be removed from ansible-core version 2.23. Use `available_variables`
instead.
+
+To resolve this, use the ``Templar.available_variables`` attribute instead.
+
+.. DWCODE: templar_loader
+
+Accessing ``Templar._loader``
+-----------------------------
+
+Direct access to the ``_loader`` internal attribute of the ``Templar`` class
is deprecated.
+
+Accessing that internal variable will result in the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Direct access to the `_loader` internal attribute
is deprecated. This feature will be
+ removed from ansible-core version 2.23. Use `copy_with_new_env` to create
a new instance.
+
+Use the ``Templar.copy_with_new_env()`` method if you only need a derived
``Templar`` instance. If you need the
+data loader itself, keep a reference to the ``DataLoader`` you created rather
than reading it back from the
+``Templar``, since the attribute it is stored in is internal and subject to
change.
+
+.. DWCODE: templar_environment
+
+Accessing ``Templar.environment``
+---------------------------------
+
+Direct access to the ``environment`` attribute of the ``Templar`` class is
deprecated.
+
+Accessing that internal variable will result in the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Direct access to the `environment` attribute is
deprecated. This feature will be
+ removed from ansible-core version 2.23. Consider using `copy_with_new_env`
or passing `overrides` to `template`.
+
+As suggested by the deprecation warning, use the
``Templar.copy_with_new_env()`` method to obtain a new
+``Templar`` instance, or use ``Templar.template()`` and set the ``overrides``
parameter.
+
+.. DWCODE: conditional_empty
+
+Empty conditional expressions
+-----------------------------
+
+Conditional expressions (such as ``when`` in playbook tasks or ``that`` in the
``assert`` action) which are a
+literal ``None`` or an empty string evaluate as True and will issue a
deprecation warning.
+
+Example
+^^^^^^^
+
+.. code-block:: yaml+jinja
+
+ - name: Print a message
+ ansible.builtin.debug:
+ msg: "test"
+ when: ""
+
+The above task will produce the following warning:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: Empty conditional expression was evaluated as True.
This feature will be removed in
+ version 2.23. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.
+
+Such expressions should be removed or corrected to always ensure a strictly
boolean (True or False) result.
+
+.. DWCODE: test_non_boolean
+
+Non-boolean test plugin results
+-------------------------------
+
+Test plugins which return a non-boolean result are deprecated; the result is
coerced to a boolean for now, but
+test plugins must have a boolean result in ansible-core 2.23 and later.
+
+Non-conforming test plugins will see a deprecation message like the following:
+
+.. code-block:: text
+
+ [DEPRECATION WARNING]: The test plugin 'my_test_plugin' returned a
non-boolean result of type <class 'NoneType'>.
+ Test plugins must have a boolean result. This feature will be removed in
version 2.23. Deprecation warnings can be
+ disabled by setting deprecation_warnings=False in ansible.cfg.
+
+To resolve this, update the test plugin to return a boolean, for example by
wrapping the result in ``bool()``.
+Starting with ansible-core 2.23, a non-boolean result is an error rather than
a warning.
+
+.. DWCODE: unknown_type_encountered_handler
+
+Templating of unknown types
+---------------------------
+
+A warning is now emitted when a type unknown to the templating system is
encountered in a finalized template result,
+since such types are not guaranteed to behave correctly.
+
+Unlike the other warnings in this section, this is a general warning rather
than a deprecation warning. Nothing is
+being removed in 2.23, and setting ``deprecation_warnings=False`` in
``ansible.cfg`` does not suppress it.
+
+Pinpointing the location of the use of the unknown type is not possible unless
you are using ``ansible-core`` 2.19
+or higher, where the origin will be displayed along with the warning. This is
a best effort notification, giving the name
+of the type that is unknown to the templating system.
+
+Warnings of this type will look similar to the following:
+
+.. code-block:: text
+
+ [WARNING]: Encountered unknown type 'NotAVariableType' during template
operation. Use supported types to avoid
+ unexpected behavior. To troubleshoot further, please upgrade to Ansible
core 2.19 or later to find out more about
+ the origin of this type.
+
+Custom data types outside of Ansible will be unsupported. Normal Python data
types (for example: ``bool``,
+``bytes``, ``dict``, ``list``, etc) and many custom Ansible data types (for
example: ``AnsibleMapping``,
+``AnsibleSequence``, ``HostVars``, etc) are supported.
Modules
=======
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/docs/docsite/rst/porting_guides/porting_guide_core_2.21.rst
new/ansible-documentation-2.21.6/docs/docsite/rst/porting_guides/porting_guide_core_2.21.rst
---
old/ansible-documentation-2.21.5/docs/docsite/rst/porting_guides/porting_guide_core_2.21.rst
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/docs/docsite/rst/porting_guides/porting_guide_core_2.21.rst
2026-11-02 13:43:20.000000000 +0100
@@ -38,7 +38,7 @@
Engine
======
-No notable changes
+utils.encrypt functions moved to depend on libcrypt/libxcrypt as the previous
passlib has been deprecated, this creates compatible password hashes, but they
will not be exactly the same as passlib did extra process and formatting. Any
code that uses these functions should still transparently work, but their
output will not match previous versions of Ansible.
.. _2.21_plugin_api:
@@ -93,7 +93,7 @@
Noteworthy plugin changes
-------------------------
-No notable changes
+password_hash filter - No changes to the filter itself, but it depends on the
utils.encrypt code, which moved from passlib (deprecated) to
libcrypt/libxcrypt, this still creates valid hashes, but they are not exactly
the same as the previous ones with the same input.
Porting custom scripts
======================
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/ansible-documentation-2.21.5/hacking/pr_labeler/pr_labeler/data/docs_team_info.md
new/ansible-documentation-2.21.6/hacking/pr_labeler/pr_labeler/data/docs_team_info.md
---
old/ansible-documentation-2.21.5/hacking/pr_labeler/pr_labeler/data/docs_team_info.md
2026-10-05 09:23:09.000000000 +0200
+++
new/ansible-documentation-2.21.6/hacking/pr_labeler/pr_labeler/data/docs_team_info.md
2026-11-02 13:43:20.000000000 +0100
@@ -1,2 +1,2 @@
-Thanks for your Ansible docs contribution! We talk about Ansible documentation
on Matrix at [#docs:ansible.im](https://matrix.to/#/#docs:ansible.im) if you
ever want to join us and chat about the docs! We meet on Matrix every Tuesday.
See [the Ansible calendar](https://forum.ansible.com/upcoming-events) for
meeting details. We welcome additions to our [weekly agenda
items](https://forum.ansible.com/t/documentation-working-group-agenda/153/7)
too. You can add the `dawgs-meeting` tag to a forum topic to bring it up at the
next meeting.
+Thanks for your Ansible docs contribution! We talk about Ansible documentation
on Matrix at [#docs:ansible.im](https://matrix.to/#/#docs:ansible.im) if you
ever want to join us and chat about the docs!
<!--- boilerplate: docs_team_info --->
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/ansible-documentation-2.21.5/tests/constraints.in
new/ansible-documentation-2.21.6/tests/constraints.in
--- old/ansible-documentation-2.21.5/tests/constraints.in 2026-10-05
09:23:09.000000000 +0200
+++ new/ansible-documentation-2.21.6/tests/constraints.in 2026-11-02
13:43:20.000000000 +0100
@@ -3,7 +3,7 @@
# This constraint file also pins other versions for which there are known
limitations.
sphinx == 7.2.5
-antsibull-docs == 2.27.0 # currently approved version
+antsibull-docs == 2.28.0 # currently approved version
sphinx-rtd-theme >= 2.0.0 # Fix 404 pages with new sphinx --
https://github.com/ansible/ansible-documentation/issues/678
rstcheck < 6 # rstcheck 6.x has problem with rstcheck.core triggered by
include files w/ sphinx directives
https://github.com/rstcheck/rstcheck-core/issues/3
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/ansible-documentation-2.21.5/tests/formatters.txt
new/ansible-documentation-2.21.6/tests/formatters.txt
--- old/ansible-documentation-2.21.5/tests/formatters.txt 2026-10-05
09:23:09.000000000 +0200
+++ new/ansible-documentation-2.21.6/tests/formatters.txt 2026-11-02
13:43:20.000000000 +0100
@@ -1,6 +1,6 @@
# This file was autogenerated by uv via the following command:
# uv pip compile --universal --output-file tests/formatters.txt
tests/formatters.in
-black==26.5.1
+black==26.10.1
# via -r tests/formatters.in
click==8.5.0
# via black
@@ -14,7 +14,7 @@
# via black
pathspec==1.1.1
# via black
-platformdirs==4.12.3
+platformdirs==4.14.2
# via black
pytokens==0.4.1
# via black
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/ansible-documentation-2.21.5/tests/requirements.txt
new/ansible-documentation-2.21.6/tests/requirements.txt
--- old/ansible-documentation-2.21.5/tests/requirements.txt 2026-10-05
09:23:09.000000000 +0200
+++ new/ansible-documentation-2.21.6/tests/requirements.txt 2026-11-02
13:43:20.000000000 +0100
@@ -6,7 +6,7 @@
# antsibull-fileutils
aiohappyeyeballs==2.7.1
# via aiohttp
-aiohttp==3.14.3
+aiohttp==3.14.5
# via
# antsibull-core
# antsibull-docs
@@ -26,7 +26,7 @@
# via antsibull-docs
antsibull-core==3.6.0
# via antsibull-docs
-antsibull-docs==2.27.0
+antsibull-docs==2.28.0
# via
# -c tests/constraints.in
# -r tests/requirements.in
@@ -60,7 +60,7 @@
# via requests
cffi==2.1.1 ; platform_python_implementation != 'PyPy'
# via cryptography
-charset-normalizer==3.5.1
+charset-normalizer==3.5.2
# via requests
click==8.5.0
# via sphinx-intl
@@ -68,7 +68,7 @@
# via
# build
# sphinx
-cryptography==50.0.1
+cryptography==50.0.2
# via -r tests/requirements.in
docutils==0.18.1
# via
@@ -82,7 +82,7 @@
# via
# aiohttp
# aiosignal
-idna==3.19
+idna==3.20
# via
# requests
# yarl
@@ -94,9 +94,9 @@
# -r tests/requirements.in
# antsibull-docs
# sphinx
-markupsafe==3.0.3
+markupsafe==3.0.4
# via jinja2
-multidict==6.8.0
+multidict==7.1.0
# via
# aiohttp
# yarl
@@ -112,24 +112,24 @@
# via yamllint
perky==0.10
# via antsibull-core
-propcache==0.5.2
+propcache==0.5.4
# via
# aiohttp
# yarl
-pycparser==3.0 ; implementation_name != 'PyPy' and
platform_python_implementation != 'PyPy'
+pycparser==3.11 ; implementation_name != 'PyPy' and
platform_python_implementation != 'PyPy'
# via cffi
-pydantic==2.13.5
+pydantic==2.14.1
# via
# antsibull-changelog
# antsibull-core
# antsibull-docs
-pydantic-core==2.46.5
+pydantic-core==2.50.1
# via pydantic
pygments==2.21.0
# via
# ansible-pygments
# sphinx
-pyproject-hooks==1.2.0
+pyproject-hooks==1.3.3
# via build
pyyaml==6.0.3
# via
@@ -214,9 +214,9 @@
# typing-inspection
typing-inspection==0.4.4
# via pydantic
-urllib3==2.7.0
+urllib3==2.8.0
# via requests
yamllint==1.38.0
# via -r tests/requirements.in
-yarl==1.24.5
+yarl==1.25.1
# via aiohttp
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/ansible-documentation-2.21.5/tests/static.txt
new/ansible-documentation-2.21.6/tests/static.txt
--- old/ansible-documentation-2.21.5/tests/static.txt 2026-10-05
09:23:09.000000000 +0200
+++ new/ansible-documentation-2.21.6/tests/static.txt 2026-11-02
13:43:20.000000000 +0100
@@ -1,4 +1,4 @@
# This file was autogenerated by uv via the following command:
# uv pip compile --universal --output-file tests/static.txt tests/static.in
-ruff==0.16.10
+ruff==0.17.3
# via -r tests/static.in
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/ansible-documentation-2.21.5/tests/typing.txt
new/ansible-documentation-2.21.6/tests/typing.txt
--- old/ansible-documentation-2.21.5/tests/typing.txt 2026-10-05
09:23:09.000000000 +0200
+++ new/ansible-documentation-2.21.6/tests/typing.txt 2026-11-02
13:43:20.000000000 +0100
@@ -6,11 +6,11 @@
# via -r tests/typing.in
argcomplete==3.7.2
# via nox
-ast-serialize==0.12.1
+ast-serialize==0.13.1
# via mypy
attrs==26.1.0
# via nox
-certifi==2026.7.22
+certifi==2026.10.23
# via requests
cffi==2.1.1 ; platform_python_implementation != 'PyPy'
# via
@@ -30,11 +30,11 @@
# via pyjwt
dependency-groups==1.3.2
# via nox
-distlib==0.4.3
+distlib==0.4.4
# via virtualenv
docutils==0.23
# via antsibull-docutils
-filelock==4.0.10
+filelock==4.2.6
# via
# python-discovery
# virtualenv
@@ -52,11 +52,11 @@
# via jinja2
mdurl==0.1.2
# via markdown-it-py
-mypy==2.4.0
+mypy==2.4.1
# via -r tests/typing.in
mypy-extensions==1.1.0
# via mypy
-nox==2026.8.17
+nox==2026.10.20
# via -r tests/typing.in
packaging==26.3
# via
@@ -65,11 +65,11 @@
# virtualenv
pathspec==1.1.1
# via mypy
-platformdirs==4.12.3
+platformdirs==4.14.2
# via
# nox
# virtualenv
-pycparser==3.0 ; implementation_name != 'PyPy' and
platform_python_implementation != 'PyPy'
+pycparser==3.12 ; implementation_name != 'PyPy' and
platform_python_implementation != 'PyPy'
# via cffi
pygithub==2.10.0
# via -r tests/../hacking/pr_labeler/requirements.txt
@@ -79,7 +79,7 @@
# via pygithub
pynacl==1.6.2
# via pygithub
-python-discovery==1.6.1
+python-discovery==1.9.0
# via
# nox
# virtualenv
@@ -89,11 +89,11 @@
# via typer
shellingham==1.5.4
# via typer
-typer==0.27.2
+typer==0.27.3
# via typer-slim
typer-slim==0.24.0
# via -r tests/../hacking/pr_labeler/requirements.txt
-types-docutils==0.23.0.20260923
+types-docutils==0.23.0.20261030
# via -r tests/typing.in
typing-extensions==4.16.0
# via
@@ -103,5 +103,5 @@
# via
# pygithub
# requests
-virtualenv==21.14.5
+virtualenv==21.15.2
# via nox
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/ansible-documentation-2.21.5/tests/zizmor.txt
new/ansible-documentation-2.21.6/tests/zizmor.txt
--- old/ansible-documentation-2.21.5/tests/zizmor.txt 2026-10-05
09:23:09.000000000 +0200
+++ new/ansible-documentation-2.21.6/tests/zizmor.txt 2026-11-02
13:43:20.000000000 +0100
@@ -1,4 +1,4 @@
# This file was autogenerated by uv via the following command:
# uv pip compile --universal --output-file tests/zizmor.txt tests/zizmor.in
-zizmor==1.30.1
+zizmor==1.31.1
# via -r tests/zizmor.in
++++++ ansible-documentation.obsinfo ++++++
--- /var/tmp/diff_new_pack.qpiLX8/_old 2026-11-06 20:00:43.234073004 +0100
+++ /var/tmp/diff_new_pack.qpiLX8/_new 2026-11-06 20:00:43.243073380 +0100
@@ -1,5 +1,5 @@
name: ansible-documentation
-version: 2.21.5
-mtime: 1791184989
-commit: 1a3791f380e9380efaa549df2e7d3e78cd8d9501
+version: 2.21.6
+mtime: 1793623400
+commit: 386eb8455b5dc5e42711a87417c06fcd17ef23c4
