From Fedora Project Wiki
(Fill out other sections (TODO: proofread))
(submitting change to fesco)
 
(4 intermediate revisions by 2 users not shown)
Line 12: Line 12:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeReadyForFesco]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 30: Line 30:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* [Announced]
* [https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/XFBTXWERQX536MEQAR2AEM77WHXIAJMH/ Announced]
* [<will be assigned by the Wrangler> Discussion thread]
* [https://discussion.fedoraproject.org/t/f42-change-proposal-ansible-11-self-contained/132053 Discussion thread]
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/3280 #3280]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
Line 39: Line 39:
The premise of the change proposal is simple — a major version update from Ansible 9 ({{package|ansible}}) / Ansible Core 2.16 ({{package|ansible-core}}) to Ansible 11 / Ansible Core 2.18. This is being filed as a Change proposal instead of a standard update due to major breaking changes.
The premise of the change proposal is simple — a major version update from Ansible 9 ({{package|ansible}}) / Ansible Core 2.16 ({{package|ansible-core}}) to Ansible 11 / Ansible Core 2.18. This is being filed as a Change proposal instead of a standard update due to major breaking changes.


Ansible Core 2.18's minimum supported Python version on target nodes is Python 3.8 - 3.13. This means that Ansible will no longer be able to interact with RHEL 8 hosts (Python 3.6) or RHEL 7 hosts (Python 2.7). Ansible Core upstream plans to be more aggressive with dropping support for older Python versions on target nodes in the feature.
Ansible Core 2.18's minimum supported Python version on target nodes is Python 3.8 - 3.13. This means that Ansible will no longer be able to interact with RHEL 8 hosts (system Python is Python 3.6) or RHEL 7 hosts (system Python is Python 2.7). Ansible Core upstream plans to be more aggressive with dropping support for older Python versions on target nodes in the feature.


Ansible 9, the last release that supports Python 2.7 and Python 3.6 target nodes, will go EOL upstream in November 2024, so we must update to the latest Ansible to continue receiving upstream support.
Ansible 9, the last release that supports Python 2.7 and Python 3.6 target nodes, will go EOL upstream in November 2024, so we must update to the latest Ansible to continue receiving upstream support.


Other than the Python changes, the collections included in Ansible 11 package will receive the usual updates to their latest major versions. Ansible Core 2.18 also includes miscellaneous to the core playbook runtime that are listed in the [https://docs.ansible.com/ansible/devel/roadmap/ROADMAP_2_18.html Ansible Core roadmap].
The collections included in the Ansible 11 package will also receive the usual updates to their latest respective major versions. See the upstream roadmaps linked in the Documentation section for more details about other more minor Ansible Core changes and the release schedules for both Ansible and Ansible Core.


== Feedback ==
== Feedback ==


(FAQ)
* What about alternative Python interpreters on RHEL 8? Can Ansible Core 2.18 use those and keep support for RHEL 8?
Kind of. The appstream repository does indeed provide [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/installing-and-using-dynamic-programming-languages_configuring-basic-system-settings#con_python-versions_assembly_introduction-to-python alternative, newer Python interpreter versions], in addition to the default system Python version. Ansible ''can'' execute modules on target nodes using an alternative Python interpreter if the <code>ansible_python_interpreter</code> var is set appropriately, but core functionality such as the <code>ansible.builtin.package</code> / <code>ansible.builtin.dnf</code> module require access to system libraries that are only available for the default system Python interpreter. Users are therefore not recommended to update to Ansible Core 2.18 if they still require compatibility with RHEL 8 hosts.
* Can a compat package with an older Ansible Core version be provided?
Maybe. Ansible Core only adds support for new Python versions in new major releases, not the minor releases in between, even though multiple major release trains receive bugfix/security support at a time. The Ansible Core 2.16 controller in Fedora 41 only works with python3.13 thanks to a downstream patch. Additionally, even with our patches, certain parts of the codebase — including the <code>ansible-test sanity</code> tooling used by Ansible Collection developers to lint their code — do not work properly with Python versions not officially supported by upstream or its test infrastructure.
If other users are interested in an Ansible Core 2.16 compat package and willing to take primary responsibility for maintenance and forward Python compatibility, please reach out to the Change owners.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 55: Line 66:
* Proposal owners:
* Proposal owners:
** Update the ansible and ansible-core packages
** Update the ansible and ansible-core packages
** Ensure Ansible Collections packages in Fedora are up to date and compatible with the latest Ansible version.
** Ensure Ansible Collections packages in Fedora are up to date and compatible with the latest Ansible Core version.


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** Ensure Ansible Collections packages in Fedora that are not maintained by the Change owners are up to date and compatible with the latest Ansible version.
** Ensure Ansible Collections packages in Fedora that are maintained by packagers other than the Change owners are up to date and compatible with the latest Ansible Core version.


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==


Ansible Core 2.18's minimum supported Python version on target nodes is Python 3.8 - 3.13. This means that Ansible will no longer be able to interact with RHEL 8 hosts (Python 3.6) or RHEL 7 hosts (Python 2.7).
Ansible Core 2.18's minimum supported Python version on target nodes is Python 3.8 - 3.13. This means that Ansible will no longer be able to interact with RHEL 8 hosts (Python 3.6) or RHEL 7 hosts (Python 2.7).


== How To Test ==
== How To Test ==


Install the latest ansible/ansible-core packages once they arrive in the Fedora repos and ensure that your existing playbooks and installed collections and roles continue to function as they did before.
Install the latest ansible/ansible-core packages once they arrive in the Fedora repos and ensure that your existing playbooks and installed collections and roles continue to function.
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


== User Experience ==
== User Experience ==
<!-- If this change proposal is noticeable by users, how will their experiences change as a result?


This section partially overlaps with the Benefit to Fedora section above. This section should be primarily about the User Experience, written in a way that does not assume deep technical knowledge. More detailed technical description should be left for the Benefit to Fedora section.
Users will have the latest version of Ansible and Ansible Core.
 
Describe what Users will see or notice, for example:
  - Packages are compressed more efficiently, making downloads and upgrades faster by 10%.
  - Kerberos tickets can be renewed automatically. Users will now have to authenticate less and become more productive. Credential management improvements mean a user can start their work day with a single sign on and not have to pause for reauthentication during their entire day.
- Libreoffice is one of the most commonly installed applications on Fedora and it is now available by default to help users "hit the ground running".
- Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
-->


== Dependencies ==
== Dependencies ==
Line 90: Line 90:


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: Revert ansible-core and ansible updates
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


== Documentation ==
== Documentation ==
Line 101: Line 100:
* [https://docs.ansible.com/ansible/devel/roadmap/ROADMAP_2_18.html Ansible Core 2.18 Roadmap]
* [https://docs.ansible.com/ansible/devel/roadmap/ROADMAP_2_18.html Ansible Core 2.18 Roadmap]
* [https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_11.html Ansible 11 Roadmap]
* [https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_11.html Ansible 11 Roadmap]


== Release Notes ==
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are at https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/ -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this change, indicate them here.  A link to upstream documentation will often satisfy this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release.
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.
-->


Update to Ansible 11 and Ansible Core 2.18, which no longer supports Python 2.7 and Python 3.6 target nodes, including EL 7 and EL 8 hosts.
Update to Ansible 11 and Ansible Core 2.18, which no longer supports Python 2.7 and Python 3.6 target nodes, including EL 7 and EL 8 hosts.

Latest revision as of 16:45, 14 October 2024

Ansible 11

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Update to Ansible 11 and Ansible Core 2.18, which no longer supports Python 2.7 and Python 3.6 target nodes, including EL 7 and EL 8 hosts.

Owner

Current status

Detailed Description

The premise of the change proposal is simple — a major version update from Ansible 9 (ansible) / Ansible Core 2.16 (ansible-core) to Ansible 11 / Ansible Core 2.18. This is being filed as a Change proposal instead of a standard update due to major breaking changes.

Ansible Core 2.18's minimum supported Python version on target nodes is Python 3.8 - 3.13. This means that Ansible will no longer be able to interact with RHEL 8 hosts (system Python is Python 3.6) or RHEL 7 hosts (system Python is Python 2.7). Ansible Core upstream plans to be more aggressive with dropping support for older Python versions on target nodes in the feature.

Ansible 9, the last release that supports Python 2.7 and Python 3.6 target nodes, will go EOL upstream in November 2024, so we must update to the latest Ansible to continue receiving upstream support.

The collections included in the Ansible 11 package will also receive the usual updates to their latest respective major versions. See the upstream roadmaps linked in the Documentation section for more details about other more minor Ansible Core changes and the release schedules for both Ansible and Ansible Core.

Feedback

(FAQ)

  • What about alternative Python interpreters on RHEL 8? Can Ansible Core 2.18 use those and keep support for RHEL 8?

Kind of. The appstream repository does indeed provide alternative, newer Python interpreter versions, in addition to the default system Python version. Ansible can execute modules on target nodes using an alternative Python interpreter if the ansible_python_interpreter var is set appropriately, but core functionality such as the ansible.builtin.package / ansible.builtin.dnf module require access to system libraries that are only available for the default system Python interpreter. Users are therefore not recommended to update to Ansible Core 2.18 if they still require compatibility with RHEL 8 hosts.

  • Can a compat package with an older Ansible Core version be provided?

Maybe. Ansible Core only adds support for new Python versions in new major releases, not the minor releases in between, even though multiple major release trains receive bugfix/security support at a time. The Ansible Core 2.16 controller in Fedora 41 only works with python3.13 thanks to a downstream patch. Additionally, even with our patches, certain parts of the codebase — including the ansible-test sanity tooling used by Ansible Collection developers to lint their code — do not work properly with Python versions not officially supported by upstream or its test infrastructure.

If other users are interested in an Ansible Core 2.16 compat package and willing to take primary responsibility for maintenance and forward Python compatibility, please reach out to the Change owners.

Benefit to Fedora

Fedora will have the latest version of Ansible and continue receiving upstream support.

Scope

  • Proposal owners:
    • Update the ansible and ansible-core packages
    • Ensure Ansible Collections packages in Fedora are up to date and compatible with the latest Ansible Core version.
  • Other developers:
    • Ensure Ansible Collections packages in Fedora that are maintained by packagers other than the Change owners are up to date and compatible with the latest Ansible Core version.

Upgrade/compatibility impact

Ansible Core 2.18's minimum supported Python version on target nodes is Python 3.8 - 3.13. This means that Ansible will no longer be able to interact with RHEL 8 hosts (Python 3.6) or RHEL 7 hosts (Python 2.7).

How To Test

Install the latest ansible/ansible-core packages once they arrive in the Fedora repos and ensure that your existing playbooks and installed collections and roles continue to function.

User Experience

Users will have the latest version of Ansible and Ansible Core.

Dependencies

Ansible Collection packages in Fedora should be tested against the new ansible-core release.

Contingency Plan

  • Contingency mechanism: Revert ansible-core and ansible updates
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

Documentation

Release Notes

Update to Ansible 11 and Ansible Core 2.18, which no longer supports Python 2.7 and Python 3.6 target nodes, including EL 7 and EL 8 hosts.