.png "Commander"){kind=icon}
@Trevor -
So we can back up a tiny bit and I will explain a little bit more ...
Ansible as a product and upstream project made major changes with Ansible version 2.9. This was the last version of Ansible that had all batteries included (meaning all modules and such) and was when it was starting to migrate to modules being in collections. It also provided a mapping of where modules would be in which collections. Prior to Ansible 2.9, you would just use firewalld module with the various options. That module technically now lives only in the ansible.posix collection. Ansible version 2.9 was released in October of 2019 - after the release of RHEL8, which is why all the collections are there.
So when we take it in terms of the OS and all batteries included users had to wait for OS or Ansible updates to get new versions of a module. This is where breaking things down into collections help. There are the included modules with Ansible core which come from the collection called ansible.builtin as they are built-in as part of the Ansible core installation.
All other collections need to be installed to get the modules and can be installed at the system-level as the root user or more commonly you have a requirements file as part of your project so you install the collections with the versions of the modules that you know work with your playbooks.
Fast-forward a bit to AAP in which we have ansible-navigator which runs a container image (execution environment) which contains ansible-core but also a bunch of collections if you are looking at the RHEL8 or RHEL9 "supported" execution environment image that comes from Red Hat. This already contains the ansible.posix collection and many more modules that we were used to having as part of "Ansible" which are things like firewalld and syncronize. These were the modules I missed the most.
So now we are using FQCN (fully-qualified collection names) to reference modules if we are doing it the proper way and not relying the translation and mapping within Ansible (as you can sometimes still get by just using short names of the modules).
My point wasn't really just about the modules it was really more about the Ansible release cycle versus the Red Hat release cycle and why the changes appeared like they did. It was more based on when RHEL was released vs. when certain versions of Ansible were released.
So now we look at lifecycle of things ...
Ansible => Upstream project contains the basic ansible and ansible-playbook commands and the built-in collection modules.
This gets updated based on the main project and has its own project goals, schedules, and deadlines.
Red Hat Ansible Core => The supported version of Ansible that is packaged and maintained by Red Hat as part of the OS release and gets updated independently from Red Hat RHEL OS.
Red Hat Ansible Automation Platform (AAP) => Uses and leverages Ansible Core (because this goes into the execution environments) and extends things for more enterprise automation with things like Controller, EDA, Private Automation Hub, Automation Mesh, etc. This is a separate subscription and entitlement from a RHEL OS entitlement.
Red Hat Enterprise Linux (RHEL) - Platform OS and main product. This is the operating system and it bundles the ansible-core package for system functions and engineering provided playbooks and roles that are shipped as an RPM for RHEL System Roles. This prevents users from needing to install collections to get modules that are no longer included as part of Ansible.
Why all of these changes ...?
Now that we have separate collections, the modules can be updated independently at any point in time and not subject to any of the "projects" or "products" schedules that have been mentioned above. This allows powerful flexibility in updating of modules quickly. For example ...
Ansible.posix is shown above when the collections were updated and they don't correspond to a particular RHEL or AAP or Ansible release. We also have "newer" collections with ever expanding modules that are developing quickly like this ...
So hopefully you can see how this change in release process and paradigm improves the process of getting useful automation utilities out to users.
