Red Hat Ansible Automation Platform Life Cycle
Contents
- Overview
- Ansible Automation Platform Included Packages and Versions
- Ansible Automation Platform Components
- Ansible automation controller
- Event-Driven Ansible controller
- Ansible automation hub
- Ansible Lightspeed with IBM watsonx Code Assistant
- Automation execution environments
- Automation decision environments
- Postgres Database Scope of Support
- Ansible Content Tools
- Hosted Services Offerings
- Ansible automation hub
- Automation analytics
- Insights for Ansible
- Ansible Automation Platform Documentation
- Ansible Automation Platform Preview and Deprecated Features
Overview
As part of a Red Hat Ansible Automation Platform subscription, customers have access to supported versions of on-premise packages, as well as hosted services provided on console.redhat.com. Red Hat provides a published product life cycle for Ansible Automation Platform so that customers and partners can properly plan, deploy, support, and maintain their on-premise automation clusters as well as hosted services that they use as part of the Ansible Automation Platform subscription.
This life cycle encompasses stated time periods for each version of Ansible Automation Platform, which is a logical grouping of many individual product components. The life cycle for each version of Ansible Automation Platform is split into production phases, each identifying the various levels of maintenance over a period of time from the initial release date. While multiple versions of Ansible Automation Platform may be supported at any one time, note that this life cycle applies to each specific version of Ansible Automation Platform and does not apply to (for example) the 1.x or 2.x major version as a whole. That is, semantic versioning rules are not used as part of Ansible Automation Platform releases (but specific contained components may).
Customers are expected to upgrade their Ansible Automation Platform environments to the most current supported version of the product in a timely fashion. Features and bug fixes target only the latest versions of the product, though some allowance may be given for high security risk items.
Ansible Automation Platform on-premises included packages and versions
| AAP version | Ansible-core Control Plane1 | Decision environments | Minimum Automation controller2 | Minimum Event-Driven Ansible controller2 | Minimum Private automation hub2 | Minimum Ansible-navigator2 | Minimum Ansible-builder2 | Required OCP version for Operator | RHEL-provided PostgreSQL version |
|---|---|---|---|---|---|---|---|---|---|
| 2.5 | ansible-core 2.16 | rulebook 1.0, de-minimal, de-supported | 4.6 | 1.1 | 4.10 | 3.4 | 3.1 | 4.12-4.17 | 15 |
| 2.4 | ansible-core 2.15 | rulebook 1.0, de-minimal, de-supported | 4.4 | 1.0 | 4.7 | 3.4 | 3.0 | 4.10-4.17 | 13 |
| 2.3 | ansible-core 2.14 | N/A | 4.3 | N/A | 4.6 | 2.2 | 1.2 | 4.9-4.12 | 13 |
| 2.2 | ansible-core 2.13 | N/A | 4.2 | N/A | 4.5 | 2.1 | 1.1 | 4.8-4.11 | 13 |
| 2.1 | ansible-core 2.12 | N/A | 4.1 | N/A | 4.4 | 1.1 | 1.0 | 4.7-4.10 | 12 |
| 1.2 | Ansible Engine 2.9** | N/A | 3.8 | N/A | 4.2 | N/A | N/A | 3.11 | 10 |
Notes:
1. This is both the minimum version of Ansible-core required to install AAP, and also the version of Ansible-core shipped inside the control plane execution environment. It is not recommended or supported to modify the control plane exection environment.
2. Minimum versions: This is the component version available when that release of AAP was made generally available. The underlying component version is likely to change as the lifecycle of AAP goes on. Updating underlying component versions will not change the version of AAP you are running. For more information this, please refer to the following blog: Bringing faster updates to Ansible Automation Platform
Ansible Automation Platform requires at minimum Python 3.8 to function as designed.
Red Hat Enterprise Linux Support
Ansible Automation Platform (AAP) tracks the Red Hat Enterprise Linux minor version release life cycle. This means Red Hat supports managing nodes running any Red Hat Enterprise Linux version in the Full, Maintenance, and EUS support phases; according to the RHEL Life Cycle page, ELS is out of scope. However, certain component version requirements are highlighted in sections below.
All future versions mentioned below are close approximations, non-definitive, and subject to change.
ansible-core supported versions
| Managed RHEL Version | Min. ansible-core version | Max. ansible-core version |
|---|---|---|
| RHEL 8 | ansible-core 2.15 | ansible-core 2.16 |
| RHEL 9 | ansible-core 2.16 | ansible-core 2.18 |
| RHEL 10 | ansible-core 2.17 | ansible-core 2.18 |
Life Cycle Dates
Ansible Automation Platform Life Cycle
Scope of Coverage
Support will be provided for use according to the published Scope of Coverage in Appendix 1 of the Red Hat Enterprise Agreement.
To encourage the rapid adoption of new technologies while keeping the high standard of stability inherent in Red Hat enterprise product, the product life cycle for Red Hat Ansible Automation Platform is divided into three phases of maintenance, described below.
Production Phases
| Life Cycle Phase | ||||
|---|---|---|---|---|
| Description | Full Support | Maintenance Support 1 | Maintenance Support 2 | Extended Life-cycle Support add-on |
| Qualified critical security fixes | Yes | Yes | Yes | Yes3 |
| Bug fixes by severity 1 | Critical and important severity issues | Critical severity issues | No | No |
| Asynchronous Security Errata (RHSA) | Yes | Yes | Yes | No |
| Asynchronous Bug Fix Errata (RHBA)2 | Yes | Yes | No | No |
| Select Software Enhancements | Yes | No | No | No |
1. Technical Support depends on the service level included in your Red Hat Ansible Automation Platform subscription agreement.
2. Red Hat may choose, as an intermediate measure, to address serious issues that have an important impact on customer business with a hotfix while a Red Hat Bug Fix Advisory is created and verified.
3. Any fixes provided for versions underneath the Extended Life-cycle support phase will be provided at Red Hat's discretion. This will not include any fixes for Python or dependency packages.
Full Support Phase
During the Full Support Phase, qualified Critical and Important Security Advisories (RHSAs) and Urgent and selected High Priority Bug Fix Advisories (RHBAs) will be released as they become available. Other errata advisories, such as Red Hat Enhancement Advisories (RHEAs), may be delivered as appropriate.
Maintenance Support 1 Phase
During the Maintenance Support phase, qualified Critical and Important Security errata advisories (RHSAs) and Urgent and Selected High Priority Bug Fix errata advisories (RHBAs) will be released as they become available. Other bug fix (RHBA) and enhancement (RHEA) errata advisories may be released at Red Hat’s discretion, but should not be expected.
Maintenance Support 2 Phase
During Maintenance Support 2, qualified Critical and Important Security errata advisories (RHSAs) will be issued and Urgent and Selected High Priority Bug Fix errata advisories (RHBAs) will likely not be delivered. Ansible Automation Platform releases in Maintenance Support 2 will be technically supported, however, software updates will likely not be provided for these releases.
Supporting Software
If supporting software (for example, PostgreSQL embedded database or the underlying operating system and/or deployment platform) has ended its product life cycle before the end of the Maintenance Support Phase, customers may be required to upgrade to the most recent version of Red Hat Ansible Automation Platform running on a supported component.
Extended Life-cycle Support Add-On
Extended Life-cycle Support (ELS) is an optional Add-On subscription for certain Red Hat Ansible Automation Platform subscriptions. The ELS Add-On is available to purchase for the continuation of support for the Red Hat Ansible Automation Platform version 1.2 until December 31st, 2024.
Red Hat Ansible Automation Platform ELS will deliver (at Red Hat discretion) Critical and Important security fixes to Ansible Automation Platform 1.2 components (Ansible Engine 2.9 & Ansible Tower 3.8).
Ansible Automation Platform Components
Ansible Automation Platform is made up of a bundle of components to enable end-to-end automation to configure systems, deploy software, and orchestrate advanced workflows. It includes resources to create, manage, and scale across the entire enterprise.
Ansible automation controller
Automation controller replaces Ansible Tower. Automation controller introduces a distributed, modular architecture with a decoupled control and execution plane. The name change reflects these enhancements and the overall position within the Ansible Automation Platform suite.
Automation controller provides a standardized way to define, operate and delegate automation across the enterprise. It also introduces new, exciting technologies and an enhanced architecture that enables automation teams to scale and deliver automation rapidly to meet ever-growing business demand.
| Supported Activities | Unsupported Activities |
|---|---|
| Installation | Database Replication/Failover, Customer-Provided Database |
| Upgrades | External applications integrated with automation controller (i.e. third party loggers, load balancers, or authentication) |
| Backup/Restore | Playbook development and debugging |
| Standard configuration | Custom configuration |
| Usage (API and UI) | Custom API integrations |
| Operation | Custom inventory plugins and credentials |
Event-Driven Ansible controller
Event-Driven Ansible is the newest capability of Ansible Automation Platform that is designed to enable automated response with user-defined, rules-based workflows. Event-Driven Ansible works by receiving events from third party tools, deciding on the actions to take and acting automatically.
| Supported Activities | Unsupported Activities |
|---|---|
| Installation | Database Replication/Failover, Customer-Provided Database |
| Upgrades | External applications integrated with EDA controller (i.e. third party loggers or authentication) |
| Standard configuration | Custom configurations |
| Usage (UI) | Custom API integrations |
| Operation | Custom content including rulebook development and debugging, or event source and event filter plugins |
Ansible automation hub
Automation Hub allows you to discover and utilize new certified automation content from Red Hat Ansible and Certified Partners. On Ansible Automation Hub, you can discover and manage Ansible Collections, which is supported automation content developed by both partners and Red Hat for use cases such as cloud automation, network automation, security automation, and more.
| Supported Activities | Unsupported Activities |
|---|---|
| Installation | Database Replication/Failover, Customer-Provided Database |
| Upgrades | External applications integrated with automation hub (i.e. third party loggers, load balancers, or authentication) |
| Backup/Restore | Custom content/collection development and debugging |
| Standard configuration | Custom configurations |
| Usage (API and UI) | Custom API integrations |
| Operation |
Ansible Lightspeed with IBM watsonx Code Assistant
Red Hat Ansible Lightspeed with IBM watsonx Code Assistant is a generative AI service available to Red Hat Ansible Automation Platform users. Tapping into automation-specific foundation models, it uses natural language processing to turn written prompts into code snippets for the creation of Ansible playbooks. Red Hat Ansible Lightspeed with IBM watsonx Code Assistant leverages a specially trained, Ansible-specific IBM watsonx Granite model provided, managed, and maintained by IBM.
Product Documentation for Red Hat Ansible Lightspeed with IBM watsonx Code Assistant
| Supported Activities | Unsupported Activities |
|---|---|
| Installation through Ansible VS Code Extension by Red Hat | Installation through other third party IDEs |
| Standard configuration | Customized configuration such as language model customization 1 |
| Operation and usage including verifying service status | Custom content development, debugging, and quality verification of generative content suggestions 2 |
1. Additional support specific to watsonx Code Assistant can be provided directly through IBM support.
2. Feedback specific to content suggestions provided through Ansible Lightspeed should be provided directly through the Ansible Lightspeed Feedback interface in VS Code.
Automation execution environments
The functionality of ansible-engine as a component of automation controller (formerly Tower) has been replaced by automation execution environments. In addition, so has the ability to build and deploy Python virtual environments. Unlike legacy virtual environments, execution environments are container images that make it possible to incorporate system-level dependencies and collection-based content. Each execution environment allows you to have a customized image to run jobs, and each of them contain only what you need when running the job, nothing more.
Automation exection environment life cycle
Ansible engineering and product will always do our best to align the lifecycles of AAP and available execution environment, but this is not always possible. Because of this, we maintain a separate Ansible Automation Execution Environment Life Cycle.
Ansible-core
Included in each execution environment shipped with Ansible Automation Platform is Ansible core. Ansible core, or ansible-core is the main building block and architecture for Ansible, and includes:
- CLI tools such as ansible-playbook, ansible-doc. and others for driving and interacting with automation.
- The Ansible language that uses YAML to create a set of rules for developing Ansible Playbooks and includes functions such as conditionals, blocks, includes, loops, and other Ansible imperatives.
- An architectural framework that allows extensions through Ansible collections.
| Support | Do Not Support |
|---|---|
| Installation | Modified modules, plug-ins, etc. |
| Usage | Playbook development and debugging |
| Configuration | Design |
| Fully supported collections maintained by Red Hat | Community collections |
| Certified collections from our partners | Technology/Developer Preview features |
| Connection, Inventory, Fact Plugins | Custom code through scripts, plugins, and modules |
Managed node supportability
Below is a list of operating systems that are supported as managed nodes.
| Managed Nodes |
|---|
Red Hat Enterprise Linux Server 6,7,8,9 1 Ubuntu (x86_64 only): Windows Server2: Network Devices3: IBM Operating Systems4: |
Additional operating systems such as unlisted RHEL variants, SuSE, Solaris, etc. are available for Commerically-reasonable support only (i.e. issue can be replicated on a supported platform)
Notes:
1. Depending on what version is being managed, you may need to set ansible_python_interpreter to the correct python path.
2. Windows nodes only support the connection via WinRM,vPSRP, or OpenSSH. OpenSSH is supported in Windows Server 2022+ and Ansible core 2.18+. Additionally, Desktop/laptop devices and devices running desktop variants of supported operating systems (e.g. Windows 10/11) are not covered by commercially reasonable support unless a support exception has been granted with agreed conditions.
3. Specific versions of ansible-core are tested against specific versions of the above network operating system platforms. Red Hat does not maintain a list of actual hardware mapped to the platforms above. Please refer to the original equipment manufacturer for complete networking hardware and software compatibility.
4. IBM-managed nodes are tested and supported by IBM and require a valid support contract with IBM. Please refer to the following for more details: Ansible Support for IBM operating systems and content
Notes on Extended Life Phases:
Ansible-core 2.12: An extended life phase for Ansible-core 2.12 was specifically available to manage legacy RHEL systems until the End of Life phase for RHEL 6 on June 30, 2024. It is considered Maintenance Phase 2 in terms of receiving fixes and is only supported when being used specifically to manage legacy RHEL nodes.
Ansible execution environment container
| Supported Activities | Unsupported Activities |
|---|---|
| Installation | Modified Collections |
| Usage via automation content navigator | Customer-created execution environments not using base supported container images from Red Hat Container Registry |
| Configuration | Playbook development and debugging |
| Included collections via Ansible core component | Design |
| Included collections developed and supported by Ansible | Not included community collections |
| Included certified collections (passthrough to certified partner via TSAnet) | Custom code through scripts, plugins, and modules |
| Connection, Inventory, Fact Plugins included in Ansible Core component | Direct usage of Python or Ansible Runner components |
Automation decision environments
In decision environments, sources inject external events into the rulebook for processing and are typically Python code that are distributed through ansible-collections. Event-Driven Ansible includes, by default, an ansible.eda collection, which contains some sample sources, event filters and rulebooks. All the collections, ansible rulebooks and their dependencies use a Decision Environment, which is an image that can be run on either Podman or Kubernetes. It consists of the following:
- The python interpreter
- JAVA runtime environment
- ansible-rulebook python package
- ansible.eda collection
Ansible-rulebook
Event-Driven Ansible controller provides the interface in which Event-Driven Ansible automation performs. The Ansible rulebook provides the framework for Event-Driven Ansible automation. Ansible rulebook is essentially a collection of rulesets, which in turn, consists of one or more sources and one or more rules and conditions.
Ansible decision environment container
| Supported Activities | Unsupported Activities |
|---|---|
| Installation | Custom or modified event source/filter plugins, or content collections |
| Usage | Design |
| Configuration | |
| Certified collections |
Content Creator Tools
Execution environment builder
Using Ansible content that depends on non-default dependencies can be tricky. Packages must be installed on each node, play nicely with other software installed on the host system, and be kept in sync.
To help simplify this process, we have introduced the concept of execution environments, which you can create with the execution environment builder (ansible-builder)
| Supported Actions | Unsupported Actions |
|---|---|
| Installation/debugging utility issues on RHEL | Installation/debugging utility issues on non-RHEL platforms |
| Upgrades | Authoring/debugging EE definition |
| Configuration | Dependency issues/conflicts |
| Usage | Debugging errors with additional build steps |
Automation content navigator
The automation content navigator, or ansible-navigator is a command-based tool for creating, reviewing, and troubleshooting Ansible content, including inventories, playbooks, and collections.
A text-based user interface (TUI) for the Red Hat Ansible Automation Platform.
| Supported Actions | Unsupported Actions |
|---|---|
| Installation/debugging utility issues on RHEL | Installation/debugging utility issues on non-RHEL platforms |
| Upgrades | Playbook-specific issues (debugging/authoring) |
| Configuration | |
| Usage |
Hosted Service Offerings
At the time of this document being updated, the following software-as-a-service offerings are available at console.redhat.com, via the Ansible Automation Platform tile for customers who are entitled for access. Un-entitled customers will need to purchase a subscription for the Ansible Automation Platform from Red Hat or partner.
Automation hub
Ansible® automation hub is the central repository where you can discover and download Ansible Content Collections to automate new projects faster.
Included as a hosted service with your Red Hat® Ansible Automation Platform subscription, Ansible automation hub features Ansible Certified Content from Red Hat and more than 60 industry-leading partners.
In addition, private automation hub is an on-premise feature that allows you to store and control access to your company's user-generated content. It acts as a repository for pre-loaded Ansible validated content.
Ansible automation hub Certified Content
Red Hat Ansible Certified Content Collections focus on how to integrate with Red Hat and our partner platforms (typically in the form of modules, roles, playbooks, plug-ins, and/or documentation). Red Hat Ansible Certified Content Collections are fully supported by Red Hat.
Ansible automation hub Validated Content
Ansible validated content offers expert guidance for how to perform operations or tasks in a Red Hat or partner platform (typically in the form of roles and documentation). Some validated content may refer to a Red Hat Ansible Certified Content Collection to simplify the use of the collection. Ansible validated content is curated and tested by Red Hat to work in production with Ansible Automation Platform. Because it is customizable, it is not supported by Red Hat.
Automation analytics
Automation analytics gives you full visibility into the performance of your automation, helping you make informed, data-driven decisions so you can scale faster.
Automation analytics helps you estimate return on investment (ROI), predict the time and cost savings of future automation projects, and monitor the success or failure of jobs.
Insights for Ansible
With Insights for Ansible Automation Platform, you can monitor and proactively resolve infrastructure performance issues, system availability, and security vulnerabilities—helping to minimize compliance risks, threats, and potential downtime. Insights for Ansible Automation Platform relies on observability data from Red Hat support tickets and other inputs so you can identify root causes faster.
Maintenance and Updates Statement for Hosted Services
Glossary
Maintenance - Security and Application Bug fixes.
Updates - Application Feature Enhancements
Red Hat will maintain the presentation of all services within the Ansible Automation Platform offering. This will include the securing of the service(s) and their dependencies within console.redhat.com. Maintenance and Updates will be delivered by Red Hat to the platform.
Service Outages
Red Hat will endeavor with best intentions to have the Hosted services available at all times. Maintenance at times may require the service to become unavailable for a period of time, Red Hat will notify users of any intended outage.
