Ansible - RHEL9 vs RHEL10

[Trevor]

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

[Travis]

@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.

[Trevor]

Travis, you gave me a baby elephant to eat.  Even if I had all 32 teeth, I'd still have to eat, what you've served up, one byte at a time.  So, I've got some questions, based on this meaty carcass that you just provided.  I'll warn/alert you in advance, some may appear to be elementary, and maybe even trivial, but in order to digest this meal, I've got to chew slow.

Okay, here I go: In your 2nd paragraph, you make reference to Ansible 2.9.  Are you refering to Ansible-core, or are you refering to the full Ansible package (ansible-core, et.al)?    The only response I can digest right now is a binary one:  YES or NO

Thanks Travis

[Travis]

@Trevor -

Unfortunately, the answer to your question isn't binary, but I think I can explain with a command.

TLDR - When talking about an Ansible version, it is the version of the binary ansible command.

$  ansible --version
ansible [core 2.20.1]

Growning Elephant Version ...

When I talk about versions it is about Ansible itself. As stated in earlier attempts, it was packaged and marketed under different names for the same thing. So Ansible, the upstream project went into Red Hat as "Ansible => Ansible Engine => Ansible Core", for the evolution of product and packaging terms. AAP is built on top of the Ansible Core packages and as you can see when I run the ansible command, it shows that it is core 2.20.1 which corresponds back to the upstream project versions. 

https://docs.ansible.com/projects/ansible-core/devel/

It would appear too that there are other new changes with Ansible 2.19 (which were introduced into Ansible Core). So these changes will make it into the Red Hat Ansible Core package and AAP whenever Red Hat releases it when it is based on 2.19 or later.

So a brief history and timeline for the name ...

2012 - Early days of Ansible

Ansible with all modules included with the execution engine (ansible and ansible-playbook). Ansible Inc aquired by Red Hat in 2015.

2015 - 2019 - Red Hat owned Ansible (Engine and Tower sold separately)

Ansible Engine - Productized version of Ansible from the "upstream" project  and Red Hat provided support with an Ansible subscription with Red Hat

Ansible Tower - Productized version of AWX project

2019 - 2021 - Red Hat Automation Platform (AAP 1.x) established

Red Hat began selling a bundled subscription that included Engine and Tower and launced hosted services like Automation Hub.

2020 - Now - Red Hat current structure

Current Terms	What it is	Comparison to old way
ansible-core	The lean, "bare-bones" engine. It only contains the code to run playbooks and a few basic modules.	Formerly "Ansible Base" (2.10). This is the foundation of all versions.
Ansible (Community)	The "all-in-one" package you get via pip install ansible. It includes ansible-core plus thousands of community modules.	This is what people used to just call "Ansible" pre-2.10.
AAP 2.x	The current enterprise platform. It uses Execution Environments (containers) instead of a local engine.	Replaced the Engine/Tower model entirely.

So for a brief point of time during 2019ish timeframe, the release of AAP 1.x aligned somewhat with Ansible 2.10 which was briefly known as ansible-base, but as we know it today it is ansible-core.

Again, this is way more than you wanted, but the "marketting" terms and product terms don't always help with understanding, so it is best to think of the "thing" we are talking about which is ansible and that as a command has had versions which you can get with the ansible --version command as demonstrated above. This tells you the version of Ansible used, but not how it was packaged or the marketing name. 

If you aren't using Red Hat and AAP, there really isn't such a thing as these marketing names and you would follow the community names exactly. If you are ever curious as to what package provides it on a Red Hat system (providing it is subscribed to all the right channels), you can use a (yum)/dnf provides ansible to get the name of the package to install.

[Travis]

@Trevor -

This might also be helpful to you as it will show how things are corresponding with the ansible-core version to the productized versions of Ansible with AAP and Red Hat Enterprise Linux (RHEL).

https://access.redhat.com/support/policy/updates/ansible-automation-platform#:~:text=EE%20with%20Ans....

[Trevor]

Travis,

Just so that you'll know where the pain is coming from, it
has to do with something that I was reading, that read as
follows, "...following the stable Ansible 12 (tied to ansible-core 2.19)".
Now, when I say that, I took 2 aspirin, laid down for a couple
of hours, then I began that last query to you.

In the 1st sentence, 2nd paragraph, of your post from yesterday,
you mentioned "Ansible version 2.9".  So, as I've been known to
do, I visited another resource, and that's when I read the item
that I mentioned in the opening paragraph of this post.  Seeing
the considerable difference in version number, 12 (Ansible) vs
2.19 (ansible-core), the connection that I made to your reference
of Ansible 2.9, is that you were referring to Ansible core, even
though you did not explicity append the word "core".  So, being
the stickler for details that I am, that uncertainly launched yet
another question.

Okay, now for some GREAT news - in your post from yesterday,
where you provided the following

"TLDR - When talking about an Ansible version, it is the version of the binary ansible command."

That one, seemingly insignificant piece, was the match that lit the
fuse for me  -  Ansible version == version of the binary ansible
command!   That 1/2 teaspoon of verbage cleared  the fog!!!  If we're
talking about the binary, we ain't talking about the entire ecosystem! 
For all it's worth, when my little peanut brain sees the word "Ansible"
all by itself, I think ecosystem.  It's like if someone says New York, I'm
thinking state  versus city.  A simple attachment of the word "City" will
go along way for a brain with my limited processing capacity.  Okay,
I know the Ansible community didn't convene with the thought in mind
as to how things were going to be labeled to accommodate one
slow-learning person.  I get it!  I'm just sharing why I'm so challenged
in finding the needle, when it's not even in a haystack.

I'm pulling so hard to peel back the layers on this onion, because I
want to be able to at least semi-intelligently articulate the makeup of
the ecosystem.  

Fortunately for me, the challenge to actually use some of the pieces
in this beast don't present nearly the puzzle challenge of the naming
schemes.

I'll circle back with commentary on the other pieces that you provided
in your post from yesterday, after I have me a bowl of ice cream.

ansible-playbook -> a binary
ansible-connection -> a binary
ansible-console -> a binary
ansible-config -> a binary
ansible-doc -> a binary
ansible-galaxy -> a binary
ansible-pull -> a binary
ansible-vault -> a binary
ansible-inventory -> a binary

ansible core -> not a binary
ansible engine -> not a binary (essentially ansible core)

ansible-insanity -> that's what I'm feeling (:-)

Okay, I'm done!

Thanks Travis

[Travis]

@Trevor -

Correct on the naming being insanity as the "marketing" names have changed. So that is why I couldn't call it Ansible Core, because for Ansible 2.9, there was no ansible-core. It was just Ansible for upstream and Ansible Engine for Red Hat, which lead to more confusing terms and keeping things straight, and then briefly Ansible 2.10 had a bit of an issue with Ansible Base.

Now at least the package providing Ansible is called ansible-core in both community and Red Hat making it easier to track, but our courses are aligned to the version of AAP, which as you will see has a different version of Ansible Core if you checkout the link and lifecycle I provided. That is why my answers have been -vvvv.

[bonnevil]

@Trevor 

So, firstly, after Ansible 2.9 the upstream community changed how they distributed and versioned Ansible. The community provides it in two ways:

1. Ansible Core, the minimalist runtime tools (like the ansible, ansible-playbook, ansible-inventory, ansible-galaxy commands and so on) and just the ansible.builtin Ansible Content Collection. This continues to be versioned from 2.10+ (although 2.10 was called "Ansible Base" during the transition, and 2.11 was the first "Ansible Core").  This is what's in Fedora's ansible-core RPM.  Upstream provides this as a Python package you can install with the pipx command.
2. Ansible, a Python package provided by upstream that includes Ansible Core and a community-selected set of additional Ansible Content Collections (which might be significantly different than what Red Hat picks for the automation execution environments we use with Red Hat Ansible Automation Platform and the Ansible developer tools). You install it with pipx, as discussed in the community installation guide at docs.ansible.com.  Its versioning increases by a whole number each time they upgrade the included Y-version of Ansible Core.  So, community Ansible 4 had Ansible Core 2.11. The community Ansible 5 had Ansible Core 2.12. The community Ansible 12 has Ansible Core 2.18.  They did this because they might update their minor/patch version of community Ansible when they update an included Ansible Content Collection or fix a bug. This was closer to how the old pre-Ansible 2.9 versions were provided to upstream users.

A discussion of community release versions and how they manage them is at their upstream site: https://docs.ansible.com/projects/ansible/latest/reference_appendices/release_and_maintenance.html.

I also pulled some old blog articles out of the Wayback Machine from the Ansible 3.0.0 release that explained the changes at the time.  (The Red Hat Ansible Automation Platform blog is now https://www.redhat.com/en/blog/channel/red-hat-ansible-automation and community discussions happen at https://forum.ansible.com.)

• https://web.archive.org/web/20210524195504/https://www.ansible.com/blog/announcing-the-community-ans... 
• https://web.archive.org/web/20210623213444/https://www.ansible.com/blog/ansible-3.0.0-qa 

Red Hat provided an ansible-core package with RHEL for use with rhel-system-roles/linux-system-roles.  And then Red Hat provides Red Hat Ansible Automation Platform.

The community Ansible versions don't really map directly to Red Hat Ansible Automation Platform.  One reason for this is because Red Hat has moved away from packaging things this way to allow more flexibility. 

Red Hat supports multiple versions of Ansible Core for each Ansible Automation Platform version. As an example, Red Hat Ansible Automation Platform 2.6 runs Ansible Core from automation execution environments.  The ones used by default contain Ansible Core 2.16, but Red Hat also ships other automation execution environment containers through the Red Hat Ecosystem Catalog (catalog.redhat.com) that Ansible Automation Platform 2.6 can use that contain Ansible Core 2.17, and 2.18, and a tech preview of 2.19, each with their own set of included Ansible Content Collections.

That's not how community Ansible packages things at all. So you can't say that a given version of Ansible Automation Platform "is" Ansible 9-something or 12-something, in the community Python-package sense, for example.  You can say what versions of Ansible Core a version of Ansible Automation Platform supports, and that leads to what versions of various Ansible Content Collections will work (or are provided in Red Hat's automation execution environments).

• Information on the Red Hat Ansible Automation Platform life cycle: https://access.redhat.com/support/policy/updates/ansible-automation-platform 
• Information on the life cycle of automation execution environment containers supported/shipped by Red Hat: https://access.redhat.com/support/policy/updates/ansible-automation-platform-execution-environments

[bonnevil]

PS  I suppose that you could create a custom execution environment of your own that had exactly (or as close to as exactly as possible) a community Ansible version in it.  So, in that sense, maybe you could have Ansible Automation Platform 2.6 run different versions of community Ansible (like Ansible 10/11/12 for example).  But Red Hat probably doesn't support some of the Ansible Content Collections community is willing to ship and community might not ship everything Red Hat wants to provide...much like the differential between Fedora Linux and RHEL.  Never tried it, don't know what support would be like, you probably get to keep all the pieces when it breaks.