In today’s fast moving world, schedule driven, incremental releases may not be what customers are looking for. After gathering input from both external and internal customers, there is a definite appetite for more content driven releases.

Rather than waiting weeks to get official builds with a bug fix (schedule driven), most would like to have those builds made available within days after the code has been tested and merged (content driven). Beginning with Red Hat Ansible Automation Platform 2.3, this new release mechanism will be the norm. This blog will explain what it means for you and your processes.

 

What is Ansible Automation Platform?

From a business perspective, Ansible Automation Platform is the solution Red Hat offers its customers to reach and unleash the full potential of strategic automation.

From a technical perspective, Ansible Automation Platform is an umbrella of many components that provide automation capabilities. Some of these well known components include automation controller, Ansible automation hub, ansible-runner and ansible-core, which also have underlying dependencies.

A parallel can be easily drawn with Red Hat Enterprise Linux, which is the sum of all its components’ capabilities to run a battle tested operating system, just like Ansible Automation Platform.

 

Components versioning: How does it work?

Our engineering teams are embracing Semantic Versioning to develop and release all the components that make Ansible Automation Platform.

In Red Hat’s terminology, MAJOR.MINOR.PATCH is often referred to as x.y.z. The term z-stream release that is heavily used for Red Hat products translates to a Patch release in semver’s terminology.

Example from access.redhat.com/downloads for Ansible Automation Platform 2.2.1

To provide our customer base with the most stability within the lifecycle of a major Ansible Automation Platform release, , only z-stream releases of our (sub-)components are made available within our CDN (Content Delivery Network) repositories and our containers, limiting, to its maximum extent, the introduction of potential regression.

To provide a concrete example, automation-controller 4.2.0 came out as Ansible Automation Platform 2.2.0 went GA. As a customer, one has the guarantee that during the Ansible Automation Platform 2.2 lifecycle, only the 4.2.z/4.2.PATCH versions of automation-controller will be made available in Ansible Automation Platform 2.2 repositories.

 

Pre Ansible Automation Platform 2.3 Versioning 

Before the release of Ansible Automation Platform 2.3, not only were the components following Semantic Versioning, but so was the product itself.

This translated to Red Hat releasing Ansible Automation Platform 2.2.0 on GA date, followed a few months later by Ansible Automation Platform 2.2.1 and our engineering teams are now working on getting 2.2.2 ready.

While Semantic Versioning makes total sense at the component level ensuring only bug fixes are being merged and released, it doesn’t fit well at the product level – remember that Ansible Automation Platform is simply an umbrella of components – so as long as the components are only receiving z-stream updates, then the product as a whole receives only bug fixes updates.

The main idea behind following the semantic versioning for the product was to be able to provide an easy reference to what makes the product at a single point in time. In other words, given a z-stream version, say Ansible Automation Platform 2.2.0, everyone involved in the product knew it meant automation-controller 4.2.0 and automation-hub 4.5.0.

While this made sense to identify the top components, namely automation controller and private automation hub, it made it hard to view a single point in time of the whole product. When a new version was needed for ansible-core, ansible-runner or receptor or any other components (Ansible Automation Platform comes with close to 200 packages), should we release now and trigger a new z-stream release, wait for the next product z-stream release, release nonetheless and not worry about the “point in time” perspective? 

 

Current Ansible Automation Platform Versioning

Starting with Ansible Automation Platform 2.3, there will be no more z-stream version of the product; z-stream will only apply at the component level. Ansible Automation Platform 2.3 went GA on November 29, 2022. Product updates will continuously land in the CDN and in our container registries as they are merged, tested and released.

This new pattern will enable Red Hat to provide customers with a shorter wait time to receive updates and bug fixes. It will enable our engineering teams to work in a more agile way, and receive close to immediate feedback from our customer base.

Since the Ansible Automation Platform 2.3 release, in less than two months, the Ansible engineering team has released more than 10 updates across different components to ensure we are meeting our customers’ needs even faster than ever. A good example would be RHBA-2022:8909 that contains a critical upgrade fix. Five working days happened between the moment the issue was reported to the moment it was available to our customers.

As a customer, it means there is no Ansible Automation Platform 2.3.0 and there will be no Ansible Automation Platform 2.3.1, there is only Ansible Automation Platform 2.3. If you install Ansible Automation Platform using the online installer and run it with a few days difference, it will be entirely possible that you might not end up installing the exact same versions of our components. While component versions can be pinned as part of installation configuration, the main idea here to grasp is that component updates are now continuous and can happen anytime.

Example from access.redhat.com/downloads for Ansible Automation Platform 2.3

Since 2.3, we have already started pushing continuous updates to our CDN repositories and containers, all under the Ansible Automation Platform 2.3 umbrella. This is just the beginning.

• RHBA-2022:8909 – automation-controller 4.3.1
• RHBA-2022:9085 – automation-controller 4.3.2
• RHBA-2023:0075 – automation-controller 4.3.4
• RHBA-2023:0165 – automation-hub 4.6.3
• RHBA-2022:9033 – ansible-core-2.14.1

To stay aware of new component availability, Red Hat customers can get notified of product updates using the Customer Portal Errata Notifications preferences. Explanation of the bug addressed and the component updated will be part of the advisory description.

 

Installation Experiences

From a delivery perspective and installation process, nothing changes with regard to current practices. Ansible Automation Platform still provides:

• A lightweight RPM based installer that will pull the latest content available on the CDN.
• A bundled installer that vendors all the RPMs that will be updated every time a new RPM makes it to the CDN.
• Our operator available on Operator Hub – and its containers – that are updated every time a new RPM makes it to the CDN.

To know which version of a specific (sub-)component one is currently using, the traditional rpm -qi <package-name> can be used if one has an SSH access to the machines. For automation controller and Ansible automation hub, this information can be found through the help link on the User Interface. Finally, this information will be part of the SOS report from our support teams.

While running the online installer by default, the latest version of the packages will be pulled from the CDN. You can always pin the component’s version you want to pull by leveraging the following variables as part of your inventory file.

—
controller_package_version: 4.3.2             # The value of the desired controller package
automationhub_package_version: 4.6.3    # The value of the desired hub package

If you want a deterministic way to always be installing the same components, no matter when the installer is run, you can rely on the bundle installer that vendors all the RPM, and decide to upgrade from bundle release to bundle release. The bundle installer will always contain the latest version of the RPM and containers available on the CDN and registry.redhat.io.

 

Summary

• Beginning with Ansible Automation Platform 2.3, we will continuously deliver improvements on demand, allowing faster resolution to market time.
• We intend to build upon this initiative for other areas of improvement.
• This rollout improvement allows us to consider the effects on the overall product lifecycle.

We think this is a massive step forward to a smoother, more efficient process. Initial feedback has been very positive, but we’d love to hear more!

 

Where to go next

• Come visit us at AnsibleFest at Red Hat Summit 2023.
• Missed out on AnsibleFest 2022? Check out the Best of AnsibleFest 2022.
• Self-paced lab exercises – We have interactive, in-browser exercises to help you get started with Ansible Automation Platform.
• Try Ansible Automation Platform free for 60 days.