My proposal (something can be kick out/added and don’t go into details too much right now - if it’s OK I can raise a dedicated topic):
1. Replace package inclusion with community-approved collections process by SC. the approved collections:
docs will be present on docs.ansible.com (or maybe there’ll be just a link to Galaxy filtered with the badge)
2. Trim the package down to essential things decided by SC
[don’t focus on the details now] the new trimmed-down package will start with ansible-core, ansible.utils, ansible.posix, ansible.windows and community.core (SC will decide what to move to it from c.general)
3. SC will continue to decide what will be in the package including community.core’s content (i.e. to vote on new plugins/modules)
IMO with this approach, we’ll keep the collection maintainers motivated and users informed providing a still good batteries included package. And it doesn’t feel like more work for SC (maybe on the initial stage only)
For what it’s worth, as a regular end user I switched to ansible-core plus collections some time ago, and it’s worked very well and reduced both installation time and disk space consumption.
Like @kpfleming I have come to enjoy ansible-core plus the odd collection, but let’s not forget we may not be typical users.
I give Ansible trainings, and in many (most?) larger European companies it is quite out of the question to “simply” download stuff onto servers. Sysadmins may often at best install from whatever package repository the OS offers.
I experience that people have a hard time getting to grips with assembling their Ansible from bits and pieces; they’re much more comfortable with apt|dnf|zypper install.
That could be an argument for providing Ansible repos for packages for different distros? For example an apt repo for Debian and Ubuntu packages etc?
I’ve personally switched to using pipx for installing Ansible (done via a Ansible role that uses the deb version to install a newer version) as I found the Debian packages, (7.3.0 for the current stable version, bookworm) to be too old.
Just adding that I also may not be a typical user. I have been using the batteries-included package in the EPEL repo for some time now, but until recently, that was the only way I could get collections outside of AH. Recently, I was able to get approval to whitelist galaxy.ansible.com for a local galaxy_ng instance, so I can actually tailor what I need with ansible-core and execution environments through that.
Hence why I like the ansible-build-data requirements.yml; I can actually re-use that for collection syncing.
There are a couple of answers to this, RH promotes PAH (private automation hub/galaxy) but there is another way to avoid ‘yet another packages source’ and that is using system packaging for collections. The current ansible package is already used in this way, it just installs all the selected collections vs individual ones. I personally just prefer to have my own curated ‘file repo’ with the collection tarballs.
To answer OP’s post, I understand perfectly the maintenance cost, but just to add one data point in the discussion, as a regular lambda user of Ansible, the “all batteries included” is a major reason why I like and use that tool (and that was the initial marketing material by the way, all batteries included and agent-less) — I mostly use what’s provided by default, which is excellent, and rarely fetch additional collections.
I feel for the people who can only use packages provided by the distros they use, I moved from the RedHat ecosystem to the Debian one a long time ago — if I was forced to only use Debian Ansible packages I think it would potentially annoy me enough to join the project and get some more recent versions of Ansible into Debian Backports!
Is the Ansible package mainly of use for distro package managers?
No, it has no ‘specific’ use-case. It is used by end-users (like me on my work machine) and distro packages (to create downstream ansible packages) (and potentially for other reasons as well).
Distros normally distribute both ‘ansible’ (the community package) and ansible-core (with the former depending on the latter), just like the pypi packages.
No worries, you’re good. As someone who can only speak a single language with any degree of skill, I am eternally grateful to all of the many people in this community who I have the privilege of being able to communicate with in my own language due to their patience and skill, so thank you!
This is very fair, and I think it’s good we’re having this discussion here in the forum where hopefully it will be easier to find in the future.
I have read through it completely to refresh my memory and see if anything has changed over time, and I believe that everything I said there still applies from my POV.
It also includes some discussion about package size which is also one of your points:
One thing I brought up in the linked post is trying to address concerns about size vs. install time, and I think it would be very helpful if we framed the concerns (if install time is not the concern, then why exactly does the size matter at this scale, for example?).
One reason that I keep coming back to this is that I only ever hear size concerns from us (maintainers and power users who already by and large use individual collections).
My other thought about size and this comment, is that I don’t believe we are bloating the package for the entire community.
Right now, if you as a user have a concern about the size of the package you have the option to not use it, and individually install core and collections.
The community has a choice, because we’ve given them the opportunity to decide what is important to them and choose their own direction.
On the other hand, if you remove the package, you are removing an option even for people who have made a conscious choice to install via community package.
You don’t have to agree on their decision or reasons, but a lot of people make that choice.
Let’s keep moving.
I suggest starting polls for the Steering committee and the Community containing the following questions (not mutually exclusive):
Question 1: Stop including new collections and deprecate the package. Users will only be able to install ansible-core + selected collections manually: Yes/No
Question 2: Stop including new collections, trim down the package to ansible-core + a few collections like ansible.posix, ansible.utils, ansible.windows, community.core, etc. that will be determined later in a dedicated topic: Yes/No
Question 3: No changes. I’m happy with the package as it is now. Yes/No
Question 4: Your option here or suggest changes to the above questions.
I’m fine with that as long as these aren’t proper binding votes, but simple polls to get a better overview of what folks think. (If we actually want to vote on this, I think we need a more extensive discussion first.)
I see several posts that say, roughly, “Reason X is not a good reason to keep the Ansible package.” I see much less about the reasons why people think it would be good to get rid of the Ansible package. What problem are we trying to solve?
Another way to look at it is this. How would folks fill in one or more blanks:
“If we stopped maintaining the batteries-included Ansible package, we could stop ______.”
“If we stopped maintaining the batteries-included Ansible package, we could start _____.”
“If we stopped maintaining the batteries-included Ansible package, we would _________,”
Maybe it would help to not just ask for yes/no, but for a scale with five entries:
very much in favor
in favor
neutral
against
strictly against
Or maybe even a larger scale? Assuming that enough folks take part in the polls, this would give a better view on what folks think. Having to pick yes or no is a bit … binary
We had a similar discussion ~1-2 years ago.
Stop adding new packages is not an option, because there are no valid arguments for it. There might be come new products and softwares that simply won’t be included then, just because they doesn’t exist in point of time.
Basically an influx of new inclusion requests is the best what can happen for ansible. That just means that ansible live. People are using it and want to use it more.
In my opinion we’ve got two set of screws.
Increase the requirements for package inclusion
it’s time that SC needs more duties and not just “participate in voting”
About increasing the requirements.
Let’s take this as an example: New collection: kaytus.ksmanage · ansible-collections/ansible-inclusion · Discussion #69 · GitHub
The time gap between the creation of the collection (first commit in 5th dec 2023) and the request of inclusion (4th jan 2024) is just one month.
I can well imagine that one requirement must be, that the collection must exist at least one year. Just to see how it is used and maintained.
At least the CI must be updated with the rise of a new ansible release for example.
About more duties for the SC
Maybe that’s the only solution to get it done.
@samccann put it differently yesterday in the community meeting and I like to quote it here
if you don’t want to be part of reviewing/maintaining the package (and are on the SC) then leave the SC
Poll! Please share your opinion on the following options (we are not making any decisions now, it’s just another form of collecting public opinion).
Option 1: Stop including new collections and deprecate the package. Users will only be able to install ansible-core + selected collections manually. Instead of inclusion, the Steering Committee reviewed & approved collections can get the “community-approved” Galaxy badge, their docs will be on docs.ansible.com:
very much in favor
in favor
neutral
against
strictly against
0voters
Option 2: Stop including new collections, trim down the package to ansible-core + a few collections like ansible.posix, ansible.utils, ansible.windows, community.core, etc. that will be determined later in a dedicated topic. Instead of inclusion, the Steering Committee reviewed & approved collections can get the “community-approved” Galaxy badge and their docs will be on docs.ansible.com:
very much in favor
in favor
neutral
against
strictly against
0voters
Option 3: No changes. I’m happy with the package (and the inclusion of new collections) as it is now:
I would also propose a modification to option 2, as it feels the 3 options provided are too strong in each direction. And although option 2 is the closer to a compromise we have, I don’t think it’s enough.
IMO a lot of users start with the community package. It’s a great entry point, and also a great way to foster engagement within the community, particularly for those who strive to be included and see recognition in that.
I also see the Ansible Community Package as a way to advocate and enable people into recommended practices for Ansible collection development.
Here is an alternative to option 2 (let’s call it 4):
Option 4: Harden new collections inclusion requirements, trim down the package to ansible-core + new approved collections (with baseline ansible.* for ex. and the collections that pass the new inclusion requirements that will be determined later in a dedicated topic). Besides the inclusion of collections into the Ansible Community Package, the Steering Committee reviewed & approved collections can get the “community-approved” Galaxy badge and their docs will be on docs.ansible.com, even if they are not included in the package.
Bonus points if we can turn the new community package into a execution environment in the future as well to join the minimal and base (which could very well be option 2) EEs .
