[Vote ended on 2022-01-26] Establishing the roadmap for Ansible 6.0.0

[dmsimard]

Summary

Now that ansible 5.0 is behind us, we need to have a roadmap for ansible 6.0.

samccann kindly prepared a blank roadmap over which we need to set dates or adjust based on our needs and expectations: https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_6.rst

Beyond the usual roadmap where we define when to expect the release 6.0, I wanted to do a bit of a braindump of technical things that I would like to see happen during this cycle. These are not necessarily up for debate and may end up being split into their own issues where appropriate, it's just a single place where I'm writing these down for now.

I may add items to this list but in the meantime, in no particular order and at a high level:

• Improve package installation performance: stop shipping or installing files we have no use for
• Re-assess the state of the collections included in the ansible package: are any of them broken, unmaintained or neglected ? How should they be removed ? For example, there is at least community.azure and servicenow.servicenow that need to be taken care of.
• Continue down the road of automating the build, test & release process. Include tests for downstream packaging (such as Fedora and the Ubuntu PPA), for example: we're already building and testing the release tarball in CI, we should hook up test RPM/deb builds based on that tarball. That would be another step into eventually automating the entire process end-to-end.
• Improve testing coverage of the Ansible package: automate running ansible-test across all the packaged collections ? (debian runs ansible-test unit tests)

[Andersson007]

Agreed with the first 3 items. Could you please elaborate a bit more on the 4th one?

[dmsimard]

Agreed with the first 3 items. Could you please elaborate a bit more on the 4th one?

For Improve testing coverage of the Ansible package: automate running ansible-test across all the packaged collections ? I mean that collections typically have CI on PRs but we don't currently exercise that kind of CI on our builds of the ansible package.

I would like to do it for the ansible package itself to ensure that what we are shipping isn't broken but it's also a common practice in RPM packaging to have a %check section that runs unit or integration tests to sanity check that the built package works properly.

I don't think there is a precedent for running ansible-test in RPM packaging and I don't know to what extent we could do something like pull in Docker, container images, etc. for testing purposes. We don't need to run every unit/integration test but any coverage we can get is an improvement over the nothing we have right now.

[Andersson007]

Ah, got it now, thanks for explaining.
+1 to at least sanity and units. Not sure about integration ones as they can depend on third party infra not available for us. But we could try.

[felixfontein]

I created a roadmap proposal with dates and some planned work, so we have something to discuss: ansible/ansible#76772

(I tried to align the date intervals from the Ansible 5 roadmap to the ansible-core 2.13 dates.)

[gundalow]

+1 to ansible/ansible#76772

[felixfontein]

We discussed this at today's meeting, and decided to vote on the WIP PR (ansible/ansible#76772). Since we want the roadmap established ASAP, the vote will end in one week.

Please note that the collection inclusion dates will probably be mostly removed / adjusted depending on how the disucssion on #63 turns out. In case we keep the old process, the current dates in the roadmap are similar to the ones from the previous roadmap.

So: please vote on the roadmap PR ansible/ansible#76772 here by writing +1 for approving it and -1 for rejecting it!

[felixfontein]

+1

[tadeboro]

+1

[felixfontein]

@ansible-community/steering-committee please do not forget to vote on this one! The vote closes in two days, and so far only two/three/four (depending on how you count the implicit votes) of us voted.

[briantist]

+1

[jillr]

Apologies, I thought I had voted on this one! Thanks, Felix, for the reminder, 😄
+1

[Andersson007]

+1 you're not alone @jillr , i join your thanks to Felix:)

[acozine]

+1 for the timeline.

[jamescassell]

+1

[felixfontein]

Vote count: 8 x +1 from steering committee members (@gundalow @felixfontein @tadeboro @briantist @jillr @Andersson007 @acozine @jamescassell), no other votes. So we accepted ansible/ansible#76772 and want to have it merged.

Can someone confirm?

[acozine]

Confirmed. I see 8 +1 votes, all from steering committee members. No other votes.

[Andersson007]

8 x +1 from SC, no votes against (Community & SC)

[felixfontein]

Thanks everyone! Then we can continue the original discussion in this issue :)

[felixfontein]

A first (non-WIP) PR for Ansible 6: ansible-community/antsibull-build#394 disables the collision checks for Ansible 2.9 / ansible-base 2.10, so we can finally ship wheels for Ansible 6! (Edit: Merged by now.)

[felixfontein]

Another (non-WIP) PR for Ansible 6: ansible-community/antsibull-build#395 actually builds wheels for Ansible6+. Should be merged together with the previous one :) (Edit: Merged by now.)

[felixfontein]

I created #65 to discuss which files should actually be excluded from the Ansible 6 install. If you have opinions / wishes on that, please comment :)

[felixfontein]

Note that the first alpha release of Ansible 6 is planned in 6 weeks (see https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_6.rst#release-schedule).

This means we have to hurry up a bit with #70 and #65 so we can get ansible-community/antsibull-build#342 (or something similar) finished and approved before the first alpha.

Let's discuss this a bit at tomorrow's meeting, or write some comments here on how we should proceed.

[felixfontein]

One suggestion: wait until the end of this week for further feedback on #70. Assuming there has been no opposition to #70, start a vote on:

1. Collections included in Ansible should not use files outside of meta/, plugins/, roles/ and playbooks/
2. One of the two variants in FEEDBACK WANTED: which directories / files / file patterns should be excluded from the Ansible installation? #65 (I'll write a comment there on that in a minute) - we should get some impressions until then which variants we like.

If the vote runs for two weeks, we still have three weeks to implement the results.

[felixfontein]

Regarding 1: I've also announced this in today's Bullhorn. Let's wait for a week, and if nobody pointed out problems their collection in Ansible has with the proposal, let's vote on it.

Regarding 2: there seems to be a clear winner, if this doesn't change I'll create a vote for it next week (#65 (comment)).

[felixfontein]

The roadmap is there, and at least the planned work we put in there is done. We can create new issues for new topics related to 6.0.0, so closing this one.