Red Hat Ansible Automation Platform Life Cycle
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 | Automation controller version | Execution Environments | Ansible Navigator version | Ansible Builder version | Private Automation Hub version | RHEL Version | OCP Supported | RHEL-provided PostgreSQL version |
|---|---|---|---|---|---|---|---|---|
| 2.3 | 4.3 | core 2.14, ee-minimal, ee-supported, ee-2.9* | 2.2.0 | 1.2.0 | 4.6 | 8.4+, 9.0+ | 4.9-4.12 | 13 |
| 2.2 | 4.2 | core 2.13, ee-minimal, ee-supported, ee-2.9* | 2.1.0 | 1.1.1 | 4.5 | 8.4+, 9.0+ | 4.8-4.11 | 13 |
| 2.1 | 4.1 | core 2.12, ee-minimal, ee-supported, ee-2.9* | 1.1.0 | 1.0.1 | 4.4 | 8.4+ | 4.7-4.10 | 12 |
| 2.0 | 4.0 | core 2.11, ee-minimal, ee-supported, ee-2.9* | TBD | 1.0.0 | 4.3 | 8.4+ | 4.6-4.9 | 12 |
| 1.2 | 3.8 | Ansible Engine 2.9** | N/A | N/A | 4.2 | 7.7+, 8.2+ | 3.11 | 10 |
*The following supported execution environments include versions of Ansible Core RPMs available separately in the Red Hat Customer Portal.
**We support all layered products and their use of Ansible Engine 2.9 (including 2.9 execution environments) until the EOL of AAP 1.2. This will cover security fixes to the product.
Ansible Automation Platform requires at minimum Python 3.8 to function as designed.
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 |
| 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, 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.
For additional clarification, the below provides more detail specific to Red Hat Ansible Automation Platform not provided in the Enterprise Agreement.
Ansible automation controller
| Supported Activities | Unsupported Activities |
|---|---|
| Installation | Database Replication/Failover, Customer-Provided Database |
| Upgrades | External applications integrated with Tower (i.e. Splunk, Okta, etc) |
| Backup/Restore | Playbook development and debugging |
| Configuration | Custom API integrations |
| Usage (API and UI) | Custom inventory plugins and credentials |
| Operation | Custom configurations |
Ansible-core
| Support | Do Not Support |
|---|---|
| Installation | Modified modules, plug-ins, etc. |
| Usage | Playbook development and debugging |
| Configuration | Design |
| Core and Network Modules1 | Community Modules |
| Certified Modules2 | Technology Preview features |
| Connection, Inventory, Fact Plugins | Custom code through scripts, plugins, and modules |
1. Bug reporting (dependent on Life Cycle) and engineering bug fixes.
2. Bug reporting only
Execution Environments
The ability to build and deploy Python virtual environments for automation has been replaced by Ansible execution 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.
Below is a chart showing the supported execution environments shipped with Ansible Automation Platform, as well as the operating systems that are supported as managed nodes.
| Execution Environment | Managed Nodes |
|---|---|
ee-29-rhel8:latest ee-supported-rhel8:latest ee-minimal-rhel8:latest |
Red Hat Enterprise Linux Server 6,7,8,9 1 Ubuntu (x86_64 only): Windows Server2: Network Devices: IBM Operating Systems: |
NOTE: Certain collections may require specific versions of ansible-core. For more information, refer to the collection documentation.
NOTE: 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.
NOTE: Others - unlisted RHEL variants, SuSE, Solaris, etc. are available for commercially reasonable support only (i.e. issue can be replicated on a supported platform)
*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.
**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
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 or PSRP. OpenSSH on Windows is an experimental feature and it is not supported by Ansible Automation Subscription.
For any machine or device that can run Python, you also need Python 2 (version 2.7 or later) or Python 3 (version 3.5 or later).
Ansible execution environment container
| Supported Activities | Unsupported Activities |
|---|---|
| Installation | Modified Collections |
| Usage via Ansible 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 |
Content Creator Tools
Ansible 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 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 |
Ansible-navigator
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 updating 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.
Insights for Ansible
Insights for Ansible is provided as a user interface, and will always be using the latest version that is made available. At this time, there is no stable guaranteed API access for Insights.
Automation Hub
As part of a Red Hat Ansible Automation Platform subscription, customers have access to a supported version of Automation Hub. Red Hat provides a published product lifecycle for Automation Hub so that customers and partners can properly plan, deploy, support, and maintain their private Automation Hub(s) that they use with the Ansible Automation Platform.
This life cycle encompasses stated time periods for each version of Automation Hub, starting with 4.2. The life cycle for each version of Automation Hub 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 Automation Hub will be supported at any one time, note that this lifecycle applies to each specific version of Automation Hub (4.2, 4.3 and so on).
Customers are expected to upgrade their Automation Hub environments to the most current supported version of the product in a timely fashion. Bug fixes and feature-work will target only the latest versions of the product, though some allowance may be given for high security risk items.
Automation Services Catalog
Red Hat previously maintained the presentation of the Automation Services Catalog offering. Ansible Services Catalog was moved to an on-premise offering and was released as a tech preview as part of Ansible Automation Platform 2.2 and 2.3. Future releases of Ansible Automation Platform will not include the Services Catalog and it will be deprecated going forward.
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 endeavour 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.