-
Notifications
You must be signed in to change notification settings - Fork 9
Community collections: when to drop support for Ansible 2.9 and ansible-base 2.10? #50
Comments
(A not really related issue is that ansible-core 2.13 will have a cut down |
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). |
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. |
Ansible 2.9 Upstream Life Cycle AnnouncementThe 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: |
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). |
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:
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). |
@felixfontein - I think a similar proposal for |
At today's meeting we did vote on:
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 Dear other steering committee members (@acozine @gundalow @tadeboro @thaumos @zbr), please cast your votes directly here so we can finish this :) |
+1 for dropping 2.9 and 2.10 support in specified collection versions. |
+1 |
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 |
@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. |
I think there is no need for another vote since we already voted in both collections as far as I can tell. |
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. |
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) 😬 |
@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. |
Closing since this is done. |
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
, anddevel
. 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 everystable-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.)
The text was updated successfully, but these errors were encountered: