Currently, we only maintain Ansible major releases for 6 months. I would like to consider extending the maintenance period of Ansible 9 to accommodate users who still need to manage Python 2.7 and/or Python 3.6 target nodes. ansible-core 2.16 that is contained in Ansible 9 is the last release that will support these hosts. The Release Management WG now takes care of releases and we have three release managers who could split up the additional workload. Many collections release major releases infrequently or support multiple major releases at once, so I hope this would not be too much of a burden for collection maintainers, either.
1 Like
Hmmm just my 2c here. Adhering to python 2.7 is a big annoyance when contributing to or creating collections. To a much lesser degree so is 3.6, but it will also become more of one as time goes on.
My guess is most enterprise users would start running into problems for 2.7 on aging rhel 7 systems which have an upcoming eol. For 3.6 however it will likely be rhel 8 systems which still have a lottt of time before there eol. If the plan isn’t to tie it to those systems eol I’m not sure how much practical sense it really makes beyond a brief respite.
In most cases there isn’t a ton of need to rely on the system python installation instead of installing a secondary, more recent version. Maybe a better path could be helping users install and configure a secondary python installation on rhel 7/8 systems?
So far the main reasons we had against doing LTS relases (what this basically would amount to) were:
- Release manager time. This is now addressed.
- Inability to provide bugfixes (or features) for all collections whose main branch switched to a new major release, and who do not maintain older stable branches (or stopped maintaining the one included in an LTS release). This is still a problem.
We also need to discuss whether we want to limit this to bugfixes, or also allow new features. Here’s a big argument for allowing new features: many collections stick to the same major release for a long time, and regularly have new releases with bugfixes, but also features. They do not maintain stable branches for individual minor releases. So if you only accept bugfix releases from some point on, the chances are high that you will get no more releases at all for these collections. If you still accept new minor releases with new features, you still get regular releases (including bugfixes). (Some collections that this applies to are ansible.posix, community.crypto, community.docker, community.dns, community.sops. I’m sure there are quite a few more, but these are some I can list from the top of my head 
)
I think this proposal makes sense, if we make sure that users know what to expect from it:
- We only provide new features and bugfixes for collections that provide these. If collections do not provide any more releases for the major release cycle included in Ansible 9, they no longer get updated.
- In particular, we will not provide bugfixes or even security fixes for collections that do not provide updates for the major release cycle included in Ansible 9.
I think point 2. is the most important one here.
I’m not sure this is a real problem for Ansible 9. Collections included in Ansible 9 that support Python 2.7 will need to keep supporting that during their major release cycle that’s included in Ansible 9. Collections included in Ansible 9 that do not support Python 2.7 will continue to not support it.
5 Likes
I see a lot of problems deriving from the fact that we release a package containing code from tons of different sources. Are the benefits of doing that (the whole “batteries included” pitch) really outweighing the hassle of doing it? Personally I think it’s time to start planning for the big “ansible” package demise.
2 Likes
We’ve had the “should the ansible package continue to exist” debate at least twice that I can remember and the result is that it was deemed worth it to continue providing it.
It’s certainly ok to revisit that decision from time to time, but rather than relitigate all the same points on both sides, I would suggest that if you want to bring it up again, please start from the perspective of, “what has changed since the last decision that would change the outcome?” (in a new dedicated topic)
1 Like
Fair enough. I need to do some gitspelunking to find the old discussions, I suppose. Sorry, didn’t mean to hijack the topic.
2 Likes
A quick pointer: Ansible Community Package long term maintenance or not? · Issue #1 · ansible-community/community-topics · GitHub I’m pretty sure the topic came up more than once though, so looking through the meeting logs might also bring up some more discussions.
2 Likes
I definitely agree! Hopefully, dropping Python 2 will make it easier to contribute to core and collections. In the meantime, it would be nice to keep around support as long as the collection major versions included in the ansible package and ansible-core itself continue to support it.
Modules often need to interact with system Python libraries, and these are only packaged for the system Python. We can’t claim that RHEL 8 users can utilize an ansible version without python3.6 if even the package module doesn’t work.
1 Like
My apologies if I’m necroing a discussion, but I’m fairly new to the world of Ansible (light use for a couple of years, a bit more intensive this year) and I’m a bit concerned by the implications of the above. Maybe I don’t need to be, maybe I do.
I inventoried the systems I’m controlling with Ansible and at the moment I have some RHEL 7 systems and some RHEL 8 systems that will be out of support if Python 2.7 and 3.6 are dropped, and that’s it. I don’t care about the RHEL 7 ones because they are EOL and will be shut down around the time Ansible 10 will come out anyway, but the RHEL 8 systems are going to be around for some years.
My controller system can be kept up to date, but I don’t understand what the expected strategy is for people who need to control RHEL 8 systems in the future. Do we need to install Python 3.8 on targets manually? What if we need to install a new package? Do we need to keep an old version of Ansible around on our controllers indefinitely for compatibility? Or is the feeling that most things people want to do on RHEL 8 systems will probably continue to work, more or less, even if Python 3.6 is no longer officially supported? Should I switch those systems back to Puppet?
Sorry if some of those questions have obvious, non-worrying answers; as I said, I’m kind of new here so I am probably flailing a little and if someone wanted to enlighten me I’d be really obliged.
Hi @iay. From your comment I’ m not sure if you are using ansible-core and the Ansible Community Package or if you have Red Hat Ansible Automation Platform subscriptions, which would make some of the answers to your questions above different.
If you are using ansible-core and RHEL, I think the following blog post will help you understand the situation:
And the following ansible-core support matrix should help you map the python versions required on the control node and the target nodes:
I understood the context of the thread to be that of Ansible 9 which (correct me if I’m wrong) isn’t part of the Red Hat subscriptions but maintained by the community independently.
My controllers are not Red Hat systems, and that’s unlikely to change. So while the RHEL blog entry is interesting, it’s not directly relevant to my use case. It’s pretty clear in any case that it’s talking about “supported automation content for RHEL customers” and I don’t use any of that.
I do have Red Hat (and Red Hat adjacent) systems in my inventory that I need to control. These are mainly used for compatibility testing, so they need to be around and maintained as long as people deploying our software use them. The issue is that if the controller systems run a supported community version of Ansible then at some point in the future (May 2025 per the matrix you linked, when ansible-core 2.16 is EOL) then there will no longer be support in the community version of Ansible for the platform version of Python in RHEL 8 and I haven’t seen anyone say what people in my situation are supposed to do in June 2025 if they still need to run RHEL 8 targets.
You helpfully quoted my list of the options I was able to think of, so I won’t repeat those.
2 Likes
I opened Extend Ansible 9 lifecycle to November 2024 by gotmax23 · Pull Request #1023 · ansible/ansible-documentation · GitHub to get the ball rolling.
1 Like
It might be hard to understand why RHEL 8.9 has a newer ansible-core than RHEL 9.3 without reading the blog post mentioned.
I’d suggest making a different execution environment and freeze on an older version of Ansible for the systems that are stuck on older versions of python and then using either ansible-runner or ansible-navigator to run your automation.
1 Like
If you use EEs, you don’t need the Ansible package, and vice versa. (You cannot even install all collections from the Ansible package at once in an EE due to Python package conflicts. Or at least it failed multiple times the last times I tried it…)
Here is a vote on whether to merge Extend Ansible 9 lifecycle to November 2024 by gotmax23 · Pull Request #1023 · ansible/ansible-documentation · GitHub
Steering Committee
- Yes (i.e., merge the PR)
- No (i.e., do not merge the PR)
- Abstain
0
voters
Community
- Yes (i.e., merge the PR)
- No (i.e., do not merge the PR)
- Abstain
0
voters
@SteeringCommittee dear SC members, the above vote closes in two days, and so far only got 5 SC votes. If you haven’t, please take a look!
(Also please note that we currently have four open SC votes. The others expire on the upcoming weekend and one beginning of next week, so there’s still a bit of time, but why not already vote on them now if you haven’t already?)
1 Like
I’ll extend the vote until Monday the 29th. @SteeringCommittee members, if you haven’t voted yet, please do.
Managing entropy and volatility determines the half-life of Ansible.
1 Like
