Ansible Community Package long term maintenance or not?

[Ompragash]

SUMMARY

Before Ansible 2.10, the project typically maintained N, N-1 for bug fixes and N-2 for security fixes. When Ansible 3.0.0 released, we suggested that we would no longer ship updated releases for 2.10.x unless someone needed it or showed up to do the work. Unless mistaken, we have not seen interest from the community so far in pursuing updates for 2.10.x.

The below HackMD link talks about the implications of maintaining updates for 3.x once 4.x releases and how we might support 4.x once 5.x releases and so on.

https://hackmd.io/plQlGzcFRFGLnPXIeg3cwQ

[felixfontein]

CC @dmsimard

[felixfontein]

Details of today's discussions can be found in the log (see link in https://meetbot.fedoraproject.org/ansible-community/2021-03-31/ansible_community_meeting.2021-03-31-18.00.html). We did not come to a final conclusion today.

[dmsimard]

We've discussed this again at the meeting yesterday and have agreed to revisit this sometime in the future for now.

In summary, there are benefits to a longer maintenance cycle and while we are open to the idea, it is a non-negligible amount of work without even considering the implications of patching collections that do not backport bug and security fixes.

Maintaining a single major version of the ansible package for six months while providing the ability to install and update collections out-of-band leveraging ansible-core and ansible-galaxy is likely a good middle ground until the need for a longer maintenance cycle is voiced by the wider community.

[bbaassssiiee]

Let me create this call for a long-term Ansible here. If people still bother to learn and use Ansible for config management and to create infrastructure as code for their organizations, then it makes sense that they can use Ansible years later, and it should just work!! Stability, reliability, teachability and security matter, and are critical in tool selection. I vote for these and against too many moving parts. Add a thumb as a vote.

[tadeboro]

Currently, it is not feasible for the Ansible community to maintain a long-term supported Ansible package. The main reason is the lack of "influence" over the content we ship in the Ansible package.

The Ansible package is composed of two parts:

1. the ansible-core dependency that provides the execution engine and a few essential plugins and modules, and
2. a set of collections that provide the vast majority of plugins and modules.

People who package Ansible have no direct influence on either of the parts listed above. If we would like to have an LTS version of the ansible package, we would need two things:

1. an LTS version of the ansible-core package that the core development team supports, and
2. a commitment from the collection maintainers will support at least one major version of their collection in the long run.

And while I can see Ansible Core getting an LTS version, my community involvement suggests that convincing 100 collections maintainers to maintains something over an extended period is next to impossible. Furthermore, we have trouble ensuring collections follow even the most basic requirements, such as conforming to semantic versioning.

Right now, the best way of setting up a stable Ansible environment is to install the ansible-core package (this gives you approximately 18 months of support) and then use the ansible-galaxy tool to install collections needed by playbooks.

[bbaassssiiee]

18 months support? In many industries that is just the lead-time for software projects! Shouldn't IBM invest in Ansible to bring it up to support cycles like Red Hat used to have, like 10 years, and more years at a premium?

How can we build major plants, refineries, off-shore facilities, any enterprise software, or global infra using Ansible if there is no long time support?

[dmsimard]

Hi @bbaassssiiee and thanks for your interest.

I must clarify that this issue is not about the level of support offered by Red Hat (or IBM).

Red Hat does offer longer support and maintenance cycles for Ansible as well as certified content but this should not be confused with the support provided by the upstream project community which is composed in part of contributors outside of Red Hat as well as unpaid volunteers.

Like tadeboro mentioned, providing a LTS of the community Ansible package amounts to greatly increasing the burden of maintenance on volunteer contributors from the community and isn't realistic in the current circumstances.

[bbaassssiiee]

At the moment the online documentation advises Red Hat customers to stick with 2.9. It will only get security updates. That sounds like LTS to me.

[tadeboro]

The community does not maintain Ansible 2.9. Version 2.9 is the old monolithic package from the times before collections. The main reason that Ansible 2.9 is still alive is Ansible Tower that bundles it into a commercial offering that Red Hat still supports. But even there, you can get support for only a handful of modules and plugins while the vast majority of content has no support guarantees whatsoever.

[bbaassssiiee]

We know the 2.9 bugs and features and can work with that, we tested. Unpaid community volunteers don't have the same commitment and motivation in the long term as we hope a listed company with contracts does. The community committers may be more motivated to change Ansible now, but you can't call them, if things break badly in three years. I know, there were far too many batteries included, and collections distribute responsibilities. But after 9 years I think Ansible itself should converge to maintenance mode, LTS. If you want your star to shine brightly⭐️ create a collection for Ansible.

[gotmax23]

As one of the co-maintainers of the ansible community package in Fedora and EPEL (Extra Packages for Enterprise Linux), I would be interested in longer term support for Ansible 5. We do not do major release bumps of any packages in stable Fedoras (except in extenuating circumstances), so it would be great to have upstream support for the major versions that we ship.

Background: Currently, Fedora 36 ships with ansible-core 2.12.x and ansible 5.x.x. RHEL 8 and 9 ship with ansible-core 2.12.x that is officially supported by Red Hat, albeit for a very narrow set of usecases, and we maintain the community-supported ansible 5.x.x in EPEL.

I know that at least some of the collections already maintain separate stable branches. I think it would be helpful to collect some data on which collections already do this, and in general, solicit feedback from the collection maintainers.

[samccann]

Closing this issue out. We did decide to have longer maintenance cycle specifically for Ansible 9. See https://forum.ansible.com/t/vote-closed-on-2023-01-29-maintain-ansible-9-for-longer-than-6-months/2574 for details.

If you want to continue this discussion for other releases, please open a forum topic and thanks!