I’ve held off on posting, largely because this is super complex problem. One we haven’t felt we’ve had a perfect solution for going on years now. This topic consumes an inordinate amount of engineering time continuously trying meet the needs of users, while simultaneously acknowledging our engineering limitations. Each year, or multiple times a year we think we’ve come to a concensus, and rinse and repeat. Hopefully with what we’ve learned and past things we’ve done, we continue to get better, but alas, onto some more in depth info.
I know at first it probably seems easy to say “we’ll just keep supporting Python 3.6”. As of now our lifecycle intends to cover the 6 latest python versions. In the past, this was achievable, largely due to the release cadence of Python, and the uptake and stability of Python3. We initially decided when adding Python 3 support, that a minimum of Python 3.5 would be required, as older versions lacked in functionality to make it feasible to support both Python2 and Python3 simultaneously.
Starting with Python 3.7 all releases following have moved to a yearly release cadence. Python 3.5 support ended in September 2020, with 3.6 support ending in December 2021. We do often run into Python bugs, and lets say we run into a bug in an old version, we have a few choices: 1) Ignore it, 2) Implement a work around, 3) Submit and maintain a patch for RHEL python releases. This adds to the engineering maintenance burden as well.
On the flip side of supporting old things, we also have to support new things. We’ve worked out our upstream releases in a way that we can deliver support for the latest Python release within about 4 weeks of the Python release. This also allows Fedora to pull in the new Python version, and have a version of ansible-core that supports this.
With some of that information set aside for now, lets look at the RHEL8 lifecycle. First, we’ve never officially supported any RHEL version into its ELS, so we’ll take May 2029 as the EOL of RHEL8. By May 2029 there will theoretically be 12 Python versions to support if we start with Python 3.6, and a possible Python 3.17 releasing around October 2028.
Even with maintaining the 6 (or 7 depending on the release) latest Python versions we’ve already seen situations where functionality was deprecated, replaced, removed and then the replaced functioality has become deprecated, and replaced with new functionality. We honestly didn’t see that much turnover attempting to support Python 2 and Python 3 at the same time. It was largely 2 branches. We’re now talking about the potential of 3 or more branches, exceeding the complexity of Py2 and Py3. And while some argument could be made about skipping certain Python versions, I think ultimately we’d be in just the same situation not including support for some arbitrary Python, and probably make our matrix of supportability that much more complicated, and likely not reduce engineering effort.
Somewhere along the line, either here, or in other discussions, I probably mentioned that some version of ansible-core would remain available on these platforms for managing these platforms. Initially this was only slated for ansible-core packaged within RHEL itself, but has since been extended to AAP. Although to be clear, the support provided for this is a bit more limited than a normal upstream release, as the support only applies to critical security vulnerabilities. So bugs, features, and such wouldn’t be something that would be addressed.
For RHEL8, due to the timing of when we made the decision, ansible-core 2.16 is that version, and this selection is the outlier (and yes once you read the next sentence you may question your sanity, but relax, it’s not you who has lost it, it’s definitely me). For RHEL9, this is ansible-core 2.14, since the default Python in RHEL9 is Python 3.9, and Py3.9 was supported by an actively supported core version at the time of the decision. RHEL10 will have ansible-core 2.16 iirc.
In AAP this will require some amount of work by the users of AAP to select an appropriate EE (execution environment) and limit the inventory as needed.
I should also clarify, as I may have made statements that were sort of incorrect or misleading, in that we don’t really drop support for OSes. We drop support for Python versions. It just so happens, that as we drop support for older Python versions, the newer Python versions made available in OSes often don’t offer Python dependencies, specifically around system bindings. While python3-dnf comes to the top of the list quickly, it should be noted to support that, it requires bindings for rpm, libdnf, dnf, libcomps, and gpgme.
We recently ran through an activity to determine across all Red Hat supported collections, what python modules or python bindings would be required. This totalled up to 41 packages, about half of which are not actually python packages, but other applications that produce python bindings. I make this distinction here to indicate the added complexity of building the bindings over that of a standard python module. All in all, the agreement was that it wasn’t feasible to do the full scope of work, as it came to total of something like 1.5 years of engineering work. Could it be done to a smaller subet? Possibly, and while I think the 5 needed for dnf to function could solve some problems, for any level of playbook complexity, I think users may just find themselves stuck at one of those other missing deps.
Maybe someone will search my github repos, finding a completely unsupported repo with dnf in the name that does some things.
Anyway, I probably forgot something, and you may have questions I didn’t answer. Nevertheless, this topic is endlessly complicated. Is this why I love bourbon? Who can honestly say?
