Ansible - RHEL9 vs RHEL10

[Trevor]

What is the differnce in the packaging and distribution of
Ansible, in RHEL9 vs RHEL 10

[Chetan_Tiwary_]

@Trevor 

The transition from RHEL 9 to RHEL 10 marks a significant shift in how Red Hat approaches Ansible packaging, moving away from a "convenience bundle" toward a more streamlined, "core-first" philosophy.

In RHEL 9, users were accustomed to a more traditional experience where a simple dnf install ansible provided a large, bundled package containing both the engine and a wide array of commonly used collections and plugins. This was great for immediate convenience but resulted in a heavier footprint. RHEL 10 changes this by only providing ansiblecore. This means the base OS now ships with a lightweight, high performance engine, but it does not include the extra collections by default.

This shift has direct implications for your automation scripts and workflows. While RHEL 9 allowed you to rely on builtin modules, RHEL 10 requires an explicit installation of the specific collections you need, typically via Ansible Galaxy or the Automation Hub. Additionally, the underlying environment has been modernized.

RHEL 10 moves to Python 3.12 and a newer ecosystem, ensuring better performance and security compared to the older Python versions found in RHEL 9. Essentially, the move to RHEL 10 encourages a more modular, "install only what you use" approach to automation.

https://www.geeksforgeeks.org/devops/ansible-vs-ansible-core/ 

https://www.redhat.com/en/blog/updates-using-ansible-core-in-rhel 

https://access.redhat.com/support/policy/updates/ansible-automation-platform 

[Trevor]

Chetan, a significant shift in how things are approached is something
that I should know to expect - with Ansible packaging, and everything
else associated with the OS.  

In my opinion, by RHEL 10 only providing Ansible Core, that is an 
appropriate route to take.  If my network is comprised of only 4
systems that need to be managed, Ansible Automation Platform
(AAP) is overkill.

That move to Python 3.12 and a newer ecosystem won't add
appreciably to my  learning journey - at least I don't think it will.

Thanks for the nice lesson, along with the resources to consider in
updating my knowledgebase!

[Priyanshu20041]

@Trevor 
In RHEL 9, Ansible is distributed primarily via Application Streams, where ansible-core is included in the base OS lifecycle, and additional collections are delivered separately through Automation Hub / Ansible Galaxy. This allows Red Hat to provide a stable, supported core while keeping content flexible and updatable.

With RHEL 10, Red Hat has taken this further by decoupling Ansible even more from the OS, focusing RHEL on the minimal supported runtime ansible-core and positioning Ansible Automation Platform as the recommended way to consume fully supported automation content. This improves lifecycle independence, security patching, and consistency across hybrid environments.

Overall, the shift reflects Red Hat’s direction toward alighter OS + faster-moving automation ecosystem, while maintaining enterprise support guarantees.

Thanks for raising this — it’s a great topic for anyone planning long-term automation on RHEL.

[Trevor]

Thanks Priyanshu20041 for your response.

Your comment, "...on the minimal supported runtime
ansible-core...", prompts a question.  Who is providing
the support for ansible-core, the community or Red Hat?

Thanks in advance!

[Priyanshu20041]

 @Trevor, For RHEL-packaged ansible-core , support is provided by Red Hat—including updates, fixes, and guidance. The upstream community maintains Ansible itself, but in RHEL environments, enterprise support comes from Red Hat.

[Trevor]

Makes sense.

Thanks Priyanshu20041!

[Priyanshu20041]

You’re welcome, Trevor! Happy to help.

[Travis]

@Trevor -

I would argue this slightly differently in that while it may change the "name" and may change where it is distributed, the same principal applies. When we went to AAP, the older "ansible engine" became ansible-core. Red Hat still distributes this with RHEL9 and RHEL10 and this gives you the base ansible and ansible-playbook commands to run your Ansible automations.

The bigger differences is the collections and modules distributed. That is what really makes a difference here in that your playbooks may not run without the modules being available on the system. Red Hat has created some RPMs for the RHEL-SYSTEM-ROLES packages and this will include the needed collections, modules, playbooks and tasks that Red Hat engineering supports. 

Why does this matter ... well the firewalld module is in ansible.posix collection. This isn't installed by default, but there is a way to configure networks and firewalls using the Red Hat provided SYSTEM roles, even though your regular playbooks that used to work no longer work (unless you install the ansible.posix collection from Galaxy or Automation Hub).

The reasons for this are so that collections and modules can be updated much more quickly and easily without being tied to a version of Ansible or more importantly a version of the RHEL OS that you happen to be running.

[Trevor]

Travis, in your response, information like "...the older "ansible engine" became ansible-core" is gold for me!  No, it doesn't help with my use, but it absolutely helps when it comes to my articulation about items that comprise this Ansible ecosystem.  So, thank you for that nugget!!!

In the final (4th) paragraph of your response, you began with "The reasons for this are ..."   I'm assuming that this is explaining what you mentioned in the 3rd paragraph.  If that is the case, is your final paragraph explaining why the firewalld module is in the ansible.posix collection?