Red Hat Ansible Automation Execution Environment Life Cycle
Overview
Automation execution environments dramatically simplify how automation is executed and managed. An automation execution environment is a container image used to execute Ansible playbooks and roles. It provides a defined, consistent, portable environment for executing automation. Execution environments also provide a common language for communicating automation dependencies between automation creators, architects, and platform administrators. Ansible Automation Platform also includes access to Ansible content tools designed to make it easier to build and manage execution environments. Automation execution environments are the replacement for Ansible Engine.
This life cycle encompasses stated time periods for each execution environment that is released as part of Ansible Automation Platform. The life cycle for each execution environment, or EE, is split into production phases, each identifying the various levels of maintenance over a period of time from the initial release date.
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.
Life Cycle Dates
Ansible engineering and product will always do our best to line up with the version of Ansible Automation Platform that it is shipped with unless a version is under extended support. The life cycle of the execution environments themselves is dependent on the version of Ansible-core included inside the environment. However, because Ansible-core releases more frequently than AAP, this will not always be the case.
Ansible Automation Execution Environment Life Cycle
The namespaced Ansible Automation Execution Environment life cycles line up directly with the correlating version of AAP. Once a version of AAP goes EOL, the execution environments in that AAP namespace are removed from Red Hat catalog. The only way to obtain a pre-built EE with that version of ansible-core is to utilize the multi-stream EEs.
Ansible-core Life Cycle
Notes on Extended Life Phases:
Ansible-engine 2.9: Red Hat Ansible Automation Platform ELS will deliver (at Red Hat discretion) Critical and Important security fixes to Ansible Automation Platform 1.2 components (in the context of execution environments, this includes ee-29-rhel8).
Ansible-core 2.12: While Ansible-core 2.12 is end-of-life and no longer receiving updates, it is specifically available to manage legacy RHEL systems. It is only supported when being used specifically to manage those older RHEL nodes.
End of Life Images
By default, only actively within their lifecycle will appear on the Red Hat Ecosystem Catalog. If you have a need to pull down deprecated images, you'll need to toggle the "include deprecated" option underneath the search filter. Please note that deprecated images are no longer receiving any updates and are not supported underneath normal subscriptions.
Ansible Automation Execution Environments and ansible-core versions
| Platform Version Namespace | Included EEs | Minimum Included Ansible-core version | Minimum Included Python version | Managed RHEL Compatibility | Target Python/Powershell |
|---|---|---|---|---|---|
| ansible-automation-platform-25 |
|
ansible-core 2.16 | Python 3.10 - 3.12 | RHEL 7 - 9 |
|
| ansible-automation-platform-24 |
|
ansible-core 2.15 | Python 3.9 - 3.11 | RHEL 7 - 9 |
|
| ansible-automation-platform-23 |
|
ansible-core 2.14 | Python 3.9 - 3.11 | RHEL 7 - 9 |
|
| ansible-automation-platform-22 |
|
ansible-core 2.13 | Python 3.8 - 3.10 | RHEL 7 - 9 |
|
| ansible-automation-platform-21 |
|
ansible-core 2.12 | Python 3.8 - 3.10 | RHEL 6 - 8 |
|
Additional Execution Environments
In addition to the execution environments that ship directly with the platform, there are also a number of additional execution environments available on the Red Hat Ecosystem Catalog. The execution environments themselves are supported for the duration of their life on the Ecosystem Catalog, but included packages may not receive fixes based on their own lifecycle (see the note around supporting software below). These additional EEs contain the packages based on the ansible-core version you require. The only extra step required is verifying the tag you'd like to pull. The tag matches the ansible-core version you'd like to utilize in your EE. These tagged EEs will contain all requisite Python packages necessary.
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 |
| Qualified critical security fixes | Yes | Yes | Yes |
| Bug fixes by severity 1 | Critical and important severity issues | Critical severity issues | None |
| Asynchronous Security Errata (RHSA) | Yes | Yes | Yes |
| Asynchronous Bug Fix Errata (RHBA)2 | Yes | Yes | No |
| Select Software Enhancements | Yes | 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 to customer business with a hotfix while a Red Hat Bug Fix Advisory is created and verified.
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) may 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) may 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 the Maintenance Support 2 phase, 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, python, collection dependency, or the underlying operating system) 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 an Execution Environment running on a supported component for their use case.
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.
For additional clarification, the below provides more detail specific to Red Hat Ansible Automation Platform not provided in the Enterprise Agreement.
