Community collections: when to drop support for Ansible 2.9 and ansible-base 2.10?

[felixfontein]

Summary

Right now, most 'old' community.collections (i.e. the ones which have been around since The Split and shortly after) support all Ansible/ansible-base/ansible-core versions since 2.9.10.

This is starting to put some strain on CI resources, since this means that tests need to run against stable-2.9, stable-2.10, stable-2.11, stable-2.12, and devel. In some collections like community.general, I've already started thinning out the test matrix for older Ansible versions, to avoid the CI matrix to grow too much. But growing the matrix gets harder for every stable-2.x branch that needs to be added.

Also, for community.general and community.network, we have a lot of symlinks to handle the flatmapping; for ansible-base 2.10 and newer we could use meta/runtime.yml instead, but Ansible 2.9 support requires symlinks. While symlinks aren't a problem in the collection artefact, they are a big problem in the Ansible tarball, since Python's setup.py de-duplicates symlinks. Therefore, all modules from these collections are contained twice in the Ansible tarball.

So for both these reasons, it would be nice to eventually get rid of Ansible 2.9 support, and also ansible-base 2.10 support. Unfortunately 2.9 is (inofficially?) a LTS version, so we have to be cautious when removing support for it.

(This is nothing we should and have to do now, i.e. for the new major releases targetted at Ansible 5, but rather for one of the next major releases, i.e. in 6-12 months.)

So, how long do you think we should still support Ansible 2.9 and ansible-base 2.10? And maybe we can come up with generic rules, like "only support the latest three stable-2.x branches + devel"? (Which would mean to drop support for stable-2.9 and stable-2.10 for community.general 5.0.0 and community.network 5.0.0 in Spring 2022.)

(Also individual collections can have different stable branch coverages; this would be more like a guideline for community collections which would mostly be followed by community.general and community.network.)

[felixfontein]

(A not really related issue is that ansible-core 2.13 will have a cut down setup.py and will have wheels. We should consider also doing that for Ansible 6, and getting rid of the symlinks before that would make wheels even more awesome. Another related issue to this topic is #29.)

[tadeboro]

For collections I help maintain, we have a rule that we test against all Ansible version core supports. This currently means 2.9-2.12 + bi-weekly devel run. Once 2.13 is out, we will drop the 2.10 testing but still keep the 2.9 in the test matrix because quite a few users still use that version. Once 2.9 is not supported anymore, we will also drop that, and then we will be on the "we only test on last three Ansible releases" rule (if nothing changes upstream, that is).

[dmsimard]

So for both these reasons, it would be nice to eventually get rid of Ansible 2.9 support, and also ansible-base 2.10 support. Unfortunately 2.9 is (inofficially?) a LTS version, so we have to be cautious when removing support for it.

I am trying to find out if we can set public/upstream expectations (even broad ones) around how long ansible-2.9 and ansible-base 2.10 are expected to be maintained and will report back when I know more.

[sivel]

Ansible 2.9 Upstream Life Cycle Announcement

The life cycle and support lifetime of Ansible 2.9 has been pretty unclear since the decision to split much of the content out of Ansible and into collections. The need for caution created by such a big change meant we wanted to ensure users were properly supported and had fully functional alternatives in their upgrade pipeline.

Having released three subsequent ansible-core releases since the split, with ansible-core 2.12 releasing on Nov 8, 2021, we feel confident that the upgrade path ensures a stable platform for continued execution of existing Ansible automation.

Additionally, the community and collection owners have made significant strides in supporting and maintaining the collections that comprise the majority of the functionality and plugins in the ecosystem. This healthy activity removed any concerns about continued use and support of this content.

To better focus our resources on improving future versions of Ansible, we have decided the appropriate course of action is to announce an end to support of Ansible 2.9 for upstream use cases. The planned end of life date for upstream Ansible 2.9 is May 23, 2022 which coincides with the scheduled release of ansible-core 2.13. End of life for ansible-base 2.10 will also coincide with the scheduled release of ansible-core 2.13.

Please take note of the specific reference to "upstream use cases". While upstream support for Ansible 2.9 will cease on May 23, 2022, downstream support for customers of Ansible Automation Platform will continue to exist. The Ansible Automation Platform life cycle can be found at https://access.redhat.com/support/policy/updates/ansible-automation-platform. Please reach out to your Red Hat representatives or Support for any questions that you may have.

EDITS:

• ansible-announce
• r/ansible post

[felixfontein]

With regard to this, I would suggest to drop support for Ansible 2.9 and ansible-base 2.10 in community.general 5.0.0, which will probably be released around that date (which will probably be close the Ansible 6.0.0b1).

[felixfontein]

Explicit proposal (we can vote on): Drop support for Ansible 2.9 and ansible-base 2.10 in community.general 5.0.0, which will be released around the Ansible 6.0.0b1 and ansible-core 2.13.0 releases.

For community.general, this concretely means:

1. Removing the symlinks, using meta/runtime.yml entries instead. This actively prevents usage for modules and action plugins on Ansible 2.9 (except if you use the "extended FQCN", like "community.general.system.ufw" instead of "community.general.ufw").
2. Potentially removing some backwards compatibility code that is only needed for Ansible 2.9 (a very quick grep showed that the redis and memcached cache plugins have 2.9-specific code, as well as the a_module test plugin). Also the path_join shim implementation can be removed, since only the redirect is needed for 2.10 and later. There might be some more code a more careful search would find (I think there is also some file information copying specific code and some run_command specific code, but I'd have to search for it).
3. We will not actively try to prevent 2.9 and 2.10 users from using the modules and plugins, except by removing compatibility code. The meta/runtime.yml's requires_ansible will be bumped to >=2.11.0, but this only produces a warning on ansible-base 2.10 and no hard failure. Ansible 2.9 ignores that field anyway.

The symlinks issue (1.) will be similar for community.network, but for most other collections only 2. and 3. are relevant.

@dericcrago what do you think about a similar proposal for community.network (4.0.0 release for inclusion in Ansible 6)? Getting rid of the symlinks will also improve the Ansible package size, since symlinks are converted to duplicated file during the packaging process (by setuptools I think).

[dericcrago]

@felixfontein - I think a similar proposal for community.network is a great idea.

[felixfontein]

At today's meeting we did vote on:

Drop support for Ansible 2.9 and ansible-base 2.10 in community.general 5.0.0 and community.network 4.0.0, which will be released around the Ansible 6.0.0b1 and ansible-core 2.13.0 releases.

While we had 11 x +1, 1 x 0 and 0 x -1, there were only five steering committee votes.

+1: @Andersson007 @cidrblock @felixfontein @jamescassell @jillr
0: (none)
-1: (none)

Dear other steering committee members (@acozine @gundalow @tadeboro @thaumos @zbr), please cast your votes directly here so we can finish this :)

[tadeboro]

+1 for dropping 2.9 and 2.10 support in specified collection versions.

[gundalow]

Explicit proposal (we can vote on): Drop support for Ansible 2.9 and ansible-base 2.10 in community.general 5.0.0, which will be released around the Ansible 6.0.0b1 and ansible-core 2.13.0 releases.

+1

[felixfontein]

Since we definitely have a majority for implementing this, I've created a PR in community.general to announce this deprecation: ansible-collections/community.general#3723

[felixfontein]

@dericcrago if you want an explicit proposal for c.network to be voted on, please add it here. Though I guess it's ok to simply do the same as for c.general without another vote.

[tadeboro]

I think there is no need for another vote since we already voted in both collections as far as I can tell.

[felixfontein]

One thing to discuss is whether to bump the minimally required 2.11 version to 2.11.8 (instead of 2.11.0). 2.11.8 will be released next week, and the most important change (https://github.com/ansible/ansible/blob/stable-2.11/changelogs/CHANGELOG-v2.11.rst) is ansible/ansible#75819, which finally adds the full attribute docs fragment to stable-2.11 (until then only the main part of the fragment was available). For every module or plugin that wants to document more than check mode and diff support with attributes this is absolutely essential.

[briantist]

I hope we were not meant to have a separate vote for every collection, since I announced dropping support in mine shortly after this c.g announced and it was discussed at the meeting (in November) 😬
ansible-collections/community.hashi_vault#190

[felixfontein]

@briantist most collections can do whatever they want (assuming they stick to the general rules in https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst). It's mainly community.general and community.network which are special, and for which we need(ed) votes.

[felixfontein]

Closing since this is done.