Ansible is intended to be used to manage other platforms. Is it smart to remove support for a platform we are very likely going to see for at least the next 8 years? There are recent posts here of individuals running EL6 based platforms yet.
I like that we have the EE capability in ansible-navigator, awx, and automation-controller. I don’t think that mechanism should be the primary way to manage nodes that are otherwise supported in the ecosystem like EL8 today with Python 3.6 maintained by the EL8 team on it’s own lifecycle separate of upstream CPython.
We have Python 3.9 in EL9, this is a continuous cycle. We can expect to see Python 3.13 in October of 2024 and a currently yearly release cycle. The platform-python in EL9 is Python 3.9. The current documented target node support targets would have EL9 out of support by ansible-core by as early as an ansible-core release after October 2026 and latest by the release after October 2027.
I’ve focused on EL8 and EL9 so far; the situation is interesting when looking at Windows. The minimum PowerShell target is 3.0 which maps to Server 2008!
Having ansible-core 2.16 supported by the RHEL package management team in RHEL 8 isn’t a fix for customers running AAP2 on RHEL9 or even OpenShift that happen to have to manage RHEL 8 nodes. Then what happens in 2026 / 2027 with customers running RHEL 9.
I get the desire to want to get off of crufty Python versions as much as the next person. I personally struggled with the Python 2 and 3 changes in and out of Ansible plenty. This just seems to go against what Ansible is used for.
This post is meant to focus on is it smart or good to remove support for Python versions on managed nodes that might have their own lifecycle for that product and it’s included Python interpreter?
I’ve been wondering if there is a way to ‘properly’ use ansible-core 2.17 with RHEL 8 targets. Obviously ansible-core 2.17 cannot cope with Python 3.6 anymore, so the default Python version of RHEL 8 won’t work. But if you install a newer Python version (which I understand can be done from the system packages), you still have the problem that the dnf module requires a Python library that’s only available for Python 3.6, I think, and not for newer Python modules on RHEL 8 (but maybe this isn’t correct?) - which would effective disallow you to install software with Ansible. If my assumptions are correct (I don’t use any version of RHEL so I have no way to verify), this basically means that ansible-core 2.17 cannot ‘properly’ manage RHEL 8 targets. And as you pointed out, a few years later we’ll have the same problem with the then latest ansible-core and RHEL 9, and so on.
While thinking on whether I should ask a question, I’ve been wondering whether it would be better if more parts of ansible-core would be moved to actual collections - in fact all modules and plugins that don’t need special access to ansible-core internals. (I would even go so far to argue that most of the module utils should be moved into that collection as well.) This would at least make it easier to use an older ansible-core (that still supports the Python versions you need) without having to lose all interesting features that need ansible-core support. But also this doesn’t really solve the real problem - you “quickly” won’t be able to use the latest ansible-core version with RHEL x.
One could also ask differently, is it smart for RHEL 8 (or 9 or …) to stick to the same (and eventually very old) Python for all system things during their lifetime?
And yes, I know, usually the folks who need to administer them aren’t the ones who decided to stick to some (eventually) ancient RHEL version for a very long time.
I guess that both your question and mine have something in common: there is no good answer to them (in the sense that every answer will make a substantial amount of folks not very happy).
That’s not correct and if it’s in our docs somewhere please let us know so we can correct it. The minimum PowerShell version is now 5.1. We also align ourselves to the normal Windows support cycle so 2016 is our baseline as Server 2012 and 2012 R2 went end of life (excluding Azure) in October last year.
I am one of those who have been running ansible to manage RHEL 5 a yew years past its extended support and doing the same with RHEL6 as well. And although I find it lovely that people want to keep support for older versions it is not really necessary. People do not upgrade systems because they do not want to touch them. So even the ansible playbooks rarely get any changes to them. And you generally do not even want to upgrade the ansible version. For RHEL 5 we would load up ansible 2.5 without any issues. You just don’t touch legacy systems unless it is to fix a critical bug or to upgrade the OS.
And for initialising python on target nodes it is common to use the raw module. Unless you make your own images of course as you would then just add the newer python packages to the image from the start.
So we should at least make an effort to have one supported ansible version which support the platform python on major long term support OS, both RHEL and Debian. But the last two, three years of an OS is not as important. And even then it is not that big of a deal if the platform python version is not supported if you can install another supported python version easily. This does become more important as we see both RHEL and Debian move away from platform python.
On the controller side of things it is very different. If you upgrade to the latest version of ansible then we can assume you are also running a fairly new OS. I expect most ansible-core 2.17 to be deployed on RHEL 9 or Debian Bookworm or equivalent. And those who run on older versions do expect to have some problems such as having to install a newer version of python, possibly from EPEL instead of the official sources. So I am willing to drop support for python 3.10 on the control node. Those who still run RHEL 8 control nodes can find a way to install python 3.11 on it or use an older ansible version.
@jborean I like the idea of tying support for target nodes to levels that match support levels. As you mentioned the runtime, PowerShell, is maintained as part of that OS’ lifecycle.
As @felixfontein mentioned it’s a quagmire. Should Ansible have to author code compatible with old Python versions or should distributions be pushed to upgrade their runtimes just so modern Ansible can manage them?
I think it is reasonable to assume Ansible can communicate to and manage major Linux platforms during their lifecycle similar to Windows as an end-user. The new quagmire then of course is what is a major Linux platform? The nice thing about x versions of Python back is it’s tied to Python and not any Linux distributions.
I say this with appreciation for the product and all the hard work that goes into it. My comments come from only wanting it to be the best it can be.
While sticking to ansible-core 2.16 works, it’s a problem for users of the Ansible community package. Its version 9 is supported half a year longer than usual (until ~November 2024, same as version 10), but after that there only will be new releases for Ansible community package 11 (and newer). So you won’t get any new collection updates, including no bugfixes and no security fixes (if applicable).
At that point you basically have to install newer versions of collections yourself.
(Also note that ansible-core 2.16 will be End of Life in May 2025: Releases and maintenance — Ansible Core Documentation. As far as I understood RH will still provide fixes for it to keep the system roles in RHEL 8 working, but that’s basically it. For any other problem that doesn’t affect the system roles, there will be no more patches. This is I guess what is meant with “kind of an ‘LTS’ release”.)
