Release notes

Red Hat Ansible Automation Platform 2.5

New features, enhancements, and bug fix information

Red Hat Customer Content Services

Abstract

The release notes for Red Hat Ansible Automation Platform summarize all new features and enhancements, notable technical changes, major corrections from the previous version, and any known bugs upon general availability.

Providing feedback on Red Hat documentation

If you have a suggestion to improve this documentation, or find an error, you can contact technical support at https://access.redhat.com to open a request.

Chapter 1. Overview of Red Hat Ansible Automation Platform

Red Hat Ansible Automation Platform simplifies the development and operation of automation workloads for managing enterprise application infrastructure lifecycles. Ansible Automation Platform works across multiple IT domains, including operations, networking, security, and development, as well as across diverse hybrid environments. Simple to adopt, use, and understand, Ansible Automation Platform provides the tools needed to rapidly implement enterprise-wide automation, no matter where you are in your automation journey.

1.1. Upgrades are unsupported at this time

At the initial release of Ansible Automation Platform 2.5, upgrades from earlier releases are unsupported. Only new installations are supported. Upgrade support will follow shortly after the initial 2.5 release. However, you can deploy Event-Driven Ansible 2.5 with an existing 2.4 automation controller. For more information, see Event-Driven Ansible 2.5 with automation controller 2.4.

1.2. What is included in the Ansible Automation Platform

Ansible Automation Platform	Automation controller	Automation hub	Event-Driven Ansible controller	Insights for Ansible Automation Platform	Platform gateway (Unified UI)
2.5	4.6.0	4.10.0 hosted service	1.1.0	hosted service	1.1

1.3. Red Hat Ansible Automation Platform life cycle

Red Hat provides different levels of maintenance for each Ansible Automation Platform release. For more information, see Red Hat Ansible Automation Platform Life Cycle.

Chapter 2. New features and enhancements

2.1. Installation changes

Starting with Ansible Automation Platform 2.5, three different on-premise deployment models are fully tested. In addition to the existing RPM-based installer and operator, support for the containerized installer is being added.

As the platform moves toward a container-first model, the RPM-based installer will be removed in a future release, and a deprecation warning is being issued with the release of Ansible Automation Platform 2.5. While the RPM installer will still be supported for Ansible Automation Platform 2.5 until it is removed, the investment will focus on the container-based installation for RHEL deployments and the operator-based installation for OpenShift deployments. Upgrades from 2.4 containerized Ansible Automation Platform Technology Preview to 2.5 containerized Ansible Automation Platform are unsupported at this time.

2.2. Deployment topologies

Red Hat tests Ansible Automation Platform 2.5 with a defined set of topologies to provide you with opinionated deployment options. While it is possible to install the Ansible Automation Platform on different infrastructure topologies and with different environment configurations, Red Hat guarantees support for the topologies outlined in the following table.

At the time of the Ansible Automation Platform 2.5 GA release, a limited set of topologies are fully tested. Red Hat will regularly add new topologies to iteratively expand the scope of fully tested deployment options. As new topologies roll out, we will include them in the release notes.

The following table shows the tested topologies for Ansible Automation Platform 2.5:

Mode	Infrastructure	Description	Tested topologies
RPM	Virtual Machines/Bare Metal	The RPM installer deploys the Ansible Automation Platform on Red Hat Enterprise Linux using RPMs to install the platform on host machines. Customers manage the product and infrastructure lifecycle.	RPM enterprise topology RPM mixed enterprise topology
Containers	Virtual Machines/Bare Metal	The containerized installer deploys the Ansible Automation Platform on Red Hat Enterprise Linux by using Podman that runs the platform in containers on host machines. Customers manage the product and infrastructure lifecycle.	Container enterprise topology Container growth topology
Operator	Red Hat OpenShift	The operator uses Red Hat OpenShift operators to deploy the Ansible Automation Platform within Red Hat OpenShift. Customers manage the product and infrastructure lifecycle.	Operator enterprise topology Operator growth topology

For more information, see Tested deployment models.

2.3. Unified UI

In versions before 2.5, the Ansible Automation Platform was split into three primary services: automation controller, automation hub, and Event-Driven Ansible controller. Each service included standalone user interfaces, separate deployment configurations, and separate authentication schemas.

In Ansible Automation Platform 2.5, the platform gateway is provided as a service that handles authentication and authorization for the Ansible Automation Platform. With the platform gateway, all services that make up the Ansible Automation Platform are consolidated into a single unified UI. The unified UI provides a single entry into the Ansible Automation Platform and serves the platform user interface to authenticate and access all of the Ansible Automation Platform services from a single location.

2.3.1. Terminology changes

The Unified UI highlights the functional benefits provided by each underlying service. New UI terminology aligns to earlier names as follows:

Automation execution provides functionality from the automation controller service
Automation decisions provides functionality from the Event-Driven Ansible service
Automation content provides functionality from the automation hub service

2.4. Event-Driven Ansible functionality (Automation decisions)

With Ansible Automation Platform 2.5, Event-Driven Ansible functionality has been enhanced with the following features:

Enterprise single-sign on and role-based access control are available through a new Ansible Automation Platform UI, which enables a single point of authentication and access to all functional components as follows:
- Automation Execution (automation controller)
- Automation Decision (Event-Driven Ansible)
- Automation Content (automation hub)
- Automation Analytics
- Access Management
- Red Hat Ansible Lightspeed
Simplified event routing capabilities introduce event streams. Event streams are an easy way to connect your sources to your rulebooks. This new capability lets you create a single endpoint to receive alerts from an event source and then use the events in multiple rulebooks. This simplifies rulebook activation setup, reduces maintenance demands, and helps lower risk by eliminating the need for additional ports to be open to external traffic.
Event-Driven Ansible in the Ansible Automation Platform 2.5 now supports horizontal scalability and enables high-availability deployments of the Event-Driven Ansible controller. These capabilities allow for the installation of multiple Event-Driven Ansible nodes and thus enable you to create highly available deployments.
Migration to the new platform-wide Red Hat Ansible Automation Platform credential type replaces the legacy controller token for enabling rulebook activations to call jobs in the automation controller.
Event-Driven Ansible now has the ability to manage credentials that can be added to rulebook activations. These credentials can be used in rulebooks to authenticate to event sources. In addition, you can now attach vault credentials to rulebook activations so that you can use vaulted variables in rulebooks. Encrypted credentials and vaulted variables enable enterprises to secure the use of Event-Driven Ansible within their environment.
New modules are added to the ansible.eda collection to enable users to automate the configuration of the Event-Driven Ansible controller using Ansible playbooks.

2.5. Event-Driven Ansible 2.5 with automation controller 2.4

You can use a newly installed version of Event-Driven Ansible from Ansible Automation Platform 2.5 with some existing versions of the automation controller. A hybrid configuration is supported with the following versions:

2.4 Ansible Automation Platform version of automation controller (4.4 or 4.5)
2.5 Ansible Automation Platform version of Event-Driven Ansible (1.1)

You can only use new installations of Event-Driven Ansible in this configuration. RPM-based hybrid deployments are fully supported by Red Hat. For details on setting up this configuration, see the chapter Installing Event-Driven Ansible controller 1.1 and configuring automation controller 4.4 or 4.5 in the Using Event-Driven Ansible 2.5 with Ansible Automation Platform 2.4 guide.

A hybrid configuration means you can install a new Event-Driven Ansible service and configure rulebook activations to execute job templates on a 2.4 version of the automation controller.

2.6. Red Hat Ansible Lightspeed on-premise deployment

Red Hat Ansible Lightspeed with IBM watsonx Code Assistant is a generative AI service that helps automation teams create, adopt, and maintain Ansible content more efficiently; it is now available as an on-premise deployment on the Ansible Automation Platform 2.5.

The on-premise deployment provides the Ansible Automation Platform customers more control over their data and supports compliance with enterprise security policies. For example, organizations in sensitive industries with data privacy or air-gapped requirements can use on-premise deployments of both Red Hat Ansible Lightspeed and IBM watsonx Code Assistant for Red Hat Ansible Lightspeed on Cloud Pak for Data. Red Hat Ansible Lightspeed on-premise deployments are supported on Ansible Automation Platform 2.5. For more information, see the chapter Setting up Red Hat Ansible Lightspeed on-premise deployment in the Red Hat Ansible Lightspeed with IBM watsonx Code Assistant User Guide.

2.7. Ansible plug-ins for Red Hat Developer Hub

The Ansible plug-ins for Red Hat Developer Hub deliver an Ansible-first Red Hat Developer Hub user experience that simplifies creating Ansible content, such as playbooks and collections, for Ansible users of all skill levels. The Ansible plug-ins provide curated content and features to accelerate Ansible learner onboarding and streamline Ansible use case adoption across your organization.

The Ansible plug-ins provide the following capabilities:

A customized home page and navigation tailored to Ansible users
Curated Ansible learning paths to help users new to Ansible
Software templates for creating Ansible playbooks and collection projects that follow best practices
Links to supported development environments and tools with opinionated configurations

For more information, see the Ansible plug-ins for Red Hat Developer Hub documentation.

2.8. Ansible development tools

Ansible development tools is a suite of tools provided with the Ansible Automation Platform to help automation creators create, test, and deploy playbook projects, execution environments, and collections on Linux, MacOS, and Windows platforms. Consolidating core Ansible tools into a single package simplifies tool management and promotes recommended practices in the automation content creation experience.

Ansible development tools are distributed in an RPM package for RHEL systems, and in a supported container distribution that can be used on Linux, Mac, and Windows OS.

Ansible development tools comprise the following tools:

ansible-builder
ansible-core
ansible-lint
ansible-navigator
ansible-sign
Molecule
ansible-creator
ansible-dev-environment
pytest-ansible
tox-ansible

For more information, see Developing Ansible automation content.

2.9. Enhancements

Added the ability to provide mounts.conf or copy from a local or remote source when installing Podman. (AAP-16214)
Updated the inventory file to include the SSL key and certificate parameters for provided SSL web certificates. (AAP-13728)
Added an Ansible Automation Platform operator-version label on k8s resources created by the operator. (AAP-31058)
Added installation variables to support Postgres certificate authentication for user-provided databases. (AAP-1095)
Updated nginx to version 1.22. (AAP-15128)
Added a new configuration endpoint for the REST API. (AAP-13639)
Allowed adjustment of RuntimeDirectorySize for Podman environments at the time of installation. (AAP-11597)
Added support for the SAFE_PLUGINS_FOR_PORT_FORWARD setting for eda-server to the installation program. (AAP-21503)
Aligned inventory content to tested topologies and added comments for easier access to groups and variables when custom configurations are required. (AAP-30242)
The variable automationedacontroller_allowed_hostnames is no longer needed and is no longer supported for Event-Driven Ansible installations. (AAP-24421)
The eda-server now opens the ports for a rulebook with a source plugin that requires inbound connections only if that plugin is allowed in the settings. (AAP-17416)
The Event-Driven Ansible settings are now moved to a dedicated YAML file. (AAP-13276)
Starting with Ansible Automation Platform 2.5, customers using the controller collection (ansible.controller) have the platform collection (ansible.platform) as a single point of entry, and must use the platform collection to seed organizations, users, and teams. (AAP-31517)

Chapter 3. Deprecated features

Deprecated functionality is still included in Ansible Automation Platform and continues to be supported during this version’s support cycle. However, the functionality will be removed in a future release of Ansible Automation Platform and is not recommended for new deployments.

The following table provides information about features that were deprecated in Ansible Automation Platform 2.5:

Component	Feature
Automation controller, automation hub, and Event-Driven Ansible controller	Tokens for the automation controller and the automation hub are deprecated. If you want to generate tokens, use the platform gateway to create them. The platform gateway is the service that handles authentication and authorization for the Ansible Automation Platform. It provides a single entry into the Ansible Automation Platform and serves the platform user interface, so you can authenticate and access all of the Ansible Automation Platform services from a single location.
Automation controller and automation hub	All non-local authentications into the automation controller and automation hub are deprecated. Use the platform gateway to configure external authentications, such as SAML, LDAP, and RADIUS.
Ansible-core	The `INI` configuration option in the COLLECTIONS_PATHS is deprecated. Use the singular form COLLECTIONS_PATH instead.
Ansible-core	The environment variable ANSIBLE_COLLECTIONS_PATHS is deprecated. Use the singular form ANSIBLE_COLLECTIONS_PATH instead.
Ansible-core	Old-style Ansible vars plug-ins that use the entry points `get_host_vars` or `get_group_vars` were deprecated in ansible-core 2.16, and will be removed in ansible-core 2.18. Update the Ansible plug-in to inherit from BaseVarsPlugin and define a `get_vars` method as the entry point.
Ansible-core	The STRING_CONVERSION_ACTION configuration option is deprecated as it is no longer used in the ansible-core code base.
Ansible-core	The smart option for setting a connection plug-in is being removed as its main purpose of choosing between SSH and Paramiko protocols is now irrelevant. Select an explicit connection plug-in instead.
Ansible-core	The undocumented `vaultid` parameter in the `vault` and `unvault` filters is deprecated and will be removed in ansible-core version 2.20. Use `vault_id` instead.
Ansible-core	The string parameter `keepcache` in the `yum_repository` is deprecated.
Ansible-core	The `required` parameter in the API `ansible.module_utils.common.process.get_bin_path` is deprecated.
Ansible-core	`module_utils` - Importing the following convenience helpers from `ansible.module_utils.basic` has been deprecated: `get_exception`, `literal_eval`, `_literal_eval`, `datetime`, `signal`, `types`, `chain`, `repeat`, `PY2`, `PY3`, `b`, `binary_type`, `integer_types`, `iteritems`, `string_types`, `test_type`, `map`, and `shlex_quote`. Import the helpers from the source definition.
Ansible-core	`ansible-doc` - Role `entrypoint` attributes are deprecated and eventually will no longer be shown in `ansible-doc` from ansible-core.
Automation execution environment	Execution environment-29 will be deprecated in the next major release after Ansible Automation Platform 2.5.
Installer	The Ansible team is exploring ways to improve the installation of the Ansible Automation Platform on Red Hat Enterprise Linux, which may include changes to how components are deployed using RPM directly on the host OS. RPMs will be replaced by packages deployed into containers that are run via Podman; this is similar to how automation currently executes on Podman in containers (execution environments) on the host OS. Changes will be communicated through release notes, but removal will occur in major release versions of the Ansible Automation Platform.

3.1. Deprecated API endpoints

API endpoints that will be removed in a future release either because their functionality is being removed or superseded with other capabilities. For example, with the platform moving to a centralized authentication system in the platform gateway, the existing authorization APIs in the automation controller and automation hub are being deprecated for future releases as all authentication operations should occur in the platform gateway.

Component	Endpoint	Capability
Automation controller	`/api/o`	Token authentication is moving to the platform gateway.
Automation hub	`/api/login/keycloak`	Moving to the platform gateway.
Automation hub	`/api/v3/auth/token`	Token authentication used for pulling collections will migrate to the platform gateway tokens.
Automation controller	`/api/v2/organizations`	Moving to the platform gateway.
Automation controller	`/api/v2/teams`	Moving to the platform gateway.
Automation controller	`/api/v2/users`	Moving to the platform gateway.

Chapter 4. Removed features

Removed features are those that were deprecated in earlier releases. They are now removed from the Ansible Automation Platform, and will no longer be supported.

The following table provides information about features that are removed in Ansible Automation Platform 2.5:

Component	Feature
Automation controller	Proxy support for the automation controller has been removed. Load balancers must now point to the platform gateway instead of the controller.
ansible-lint	Support for old Ansible `include` tasks syntax is removed in version 2.16 and moved to `include_tasks` or `import_tasks`. Update content to use the currently-supported Ansible syntax, like include_tasks or import_tasks.
Event-Driven Ansible controller	Tokens for the Event-Driven Ansible controller are deprecated. Their configuration has been removed from rulebook activations, and they have been replaced with the Ansible Automation Platform credential type.
Ansible-core	Support for Windows Server versions 2012 and 2012 R2 is removed, as Microsoft’s supported end-of-life date is 10 October 2023. These versions of Windows Server are not tested in the Ansible Automation Platform 2.5 release. Red Hat does not guarantee that these features will continue to work as expected in this and future releases.
Ansible-core	In the Action plugin with an ActionBase class, the deprecated `_remote_checksum` method is now removed. Use `_execute_remote_stat` instead.
Ansible-core	The deprecated FileLock class is now removed. Add your own implementation or rely on third-party support.
Ansible-core	Python 3.9 is now removed as a supported version of the automation controller. Use Python 3.10 or later.
Ansible-core	The `include` module that was deprecated in ansible-core 2.12 is now removed. Use `include_tasks` or `import_tasks` instead.
Ansible-core	`Templar` - The deprecated `shared_loader_obj` parameter of `init` is now removed.
Ansible-core	`fetch_url` - Removed auto disabling `decompress` when gzip is not available.
Ansible-core	`inventory_cache` - Removed deprecated `default.fact_caching_prefix ini` configuration option. Use `defaults.fact_caching_prefix` instead.
Ansible-core	- `module_utils/basic.py` - Removed Python 3.5 as a supported remote version. Python version 2.7 or Python version 3.6 or later is now required. - With the removal of Python 2 support, the `yum` module and `yum action` plug-in are removed and redirected to `dnf`.
Ansible-core	`stat` - Removed the unused `get_md5` parameter.
Ansible-core	Removed the deprecated `JINJA2_NATIVE_WARNING` environment variable.
Ansible-core	Removed the deprecated `scp_if_ssh` from the ssh connection plugin.
Ansible-core	Removed the deprecated `crypt` support from `ansible.utils.encrypt`.
Execution environment	The Python link is no longer available in the ubi9-based execution environments; only python3 is. Replace scripts that use `python` or `/bin/python` with `python3` or `/bin/python3`.

Chapter 5. Changed features

Changed features are not deprecated and will continue to be supported until further notice.

The following table provides information about features that are changed in Ansible Automation Platform 2.5:

Component	Feature
Automation hub	Error codes are now changed from 403 to 401. Any API client usage relying on specific status code 403 versus 401 will have to update their logic. Standard UI usage will work as expected.
Event-Driven Ansible	The endpoints `/extra_vars` are now moved to a property within `/activations`.
Event-Driven Ansible	The endpoint `/credentials` was replaced with `/eda-credentials`. This is part of an expanded credentials capability for Event-Driven Ansible. For more information, see the chapter Setting up credentials for Event-Driven Ansible controller in the Event-Driven Ansible controller user guide.
Event-Driven Ansible	Event-Driven Ansible can no longer add, edit, or delete the platform gateway-managed resources. Creating, editing, or deleting organizations, teams, or users is available through platform gateway endpoints only. The platform gateway endpoints also enable you to edit organization or team memberships and configure external authentication.
API	Auditing of users has now changed. Users are now audited through the platform API, not through the controller API. This change applies to the Ansible Automation Platform in both cloud service and on-premise deployments.
Automation controller, automation hub, platform gateway, and Event-Driven Ansible	User permission audits the sources of truth for the platform gateway. When an IdP (SSO) is used, then the IdP should be the source of truth for user permission audits. When the Ansible Automation Platform platform gateway is used without SSO, then the platform gateway should be the source of truth for user permissions, not the app-specific UIs or APIs.

Chapter 6. Known issues

This section provides information about known issues in Ansible Automation Platform 2.5.

6.1. Ansible Automation Platform

Added the podman_containers_conf_logs_max_size variable for containers.conf to control the max log size for Podman installations. The default value is 10 MiB. (AAP-12295)
Setting the pg_host= value without any other context no longer results in an empty HOST section of the settings.py in the automation controller. As a workaround, delete the pg_host= value or set it to pg_host=''. (AAP-31915)
Using Prompt on launch for variables for job templates, workflow job templates, workflow visualizer nodes, and schedules will not show the default variables when launching the job, or when configuring the workflows and schedules. (AAP-30585)

6.2. Event-Driven Ansible

mTLS event stream creation should be disallowed on all installation methods by default. It is currently disallowed on OpenShift Container Platform installation, but not disallowed in the containerized installations or on RPM installations. (AAP-31337)
If a primary Redis node enters a failed state and a new primary node is promoted, Event-Driven Ansible workers and scheduler are unable to reconnect to the cluster. This causes activations to fail until the containers or pods are recycled. (AAP-30722)
For more information, see the KCS article Redis failover causes Event-Driven Ansible activation failures.

6.3. Ansible plug-ins for Red Hat Developer Hub

Python VS Code extension v2024.14.1 does not work in OpenShift Dev Spaces version 1.9.3, prohibiting the Ansible VS Code extension from loading. As a workaround, downgrade the Python VS Code extension version to 2024.12.3.
The Ansible Content Creator Get Started page links do not work in OpenShift Dev Spaces version 1.9.3. As a workaround, use the Ansible VS Code Command Palette to access the features.

Chapter 7. Fixed issues

This section provides information about fixed issues in Ansible Automation Platform 2.5.

7.1. Ansible Automation Platform

The installer now ensures semanage command is available when SELinux is enabled. (AAP-24396)
The installer can now update certificates without attempting to start the nginx service for previously installed environments. (AAP-19948)
Event-Driven Ansible installation now fails when the pre-existing automation controller is older than version 4.4.0. (AAP-18572)
Event-Driven Ansible can now successfully install on its own with a controller URL when the controller is not in the inventory. (AAP-16483)
Postgres tasks that create users in FIPS environments now use scram-sha-256. (AAP-16456)
The installer now successfully generates a new SECRET_KEY for controller. (AAP-15513)
Ensure all backup and restore staged files and directories are cleaned up before running a backup or restore. You must also mark the files for deletion after a backup or restore. (AAP-14986)
Postgres certificates are now temporarily copied when checking the Postgres version for SSL mode verify-full. (AAP-14732)
The setup script now warns if the provided log path does not have write permissions, and fails if default path does not have write permissions. (AAP-14135)
The linger configuration is now correctly set by the root user for the Event-Driven Ansible user. (AAP-13744)
Subject alternative names for component hosts will now only be checked for signing certificates when HTTPS is enabled. (AAP-7737)
The UI for creating and editing an organization now validates the Max hosts value. This value must be an integer and have a value between 0 and 214748364. (AAP-23270)
Installations that do not include the automation controller but have an external database will no longer install an unused internal Postgres server. (AAP-29798)
Added default port values for all pg_port variables in the installer. (AAP-18484)
XDG_RUNTIME_DIR is now defined when applying Event-Driven Ansible linger settings for Podman. (AAP-18341)*
Fixed an issue where the restore process failed to stop pulpcore-worker services on RHEL 9. (AAP-12829)
Fixed Postgres sslmode for verify-full that affected external Postgres and Postgres signed for 127.0.0.1 for internally managed Postgres. (AAP-7107)
Fixed support for automation hub content signing. (AAP-9739)
Fixed conditional code statements to align with changes from ansible-core issue #82295. (AAP-19053)
Resolved an issue where providing the database installation with a custom port broke the installation of Postgres. (AAP-30636)

7.2. Automation hub

Automation hub now uses system crypto-policies in nginx. (AAP-17775)

7.3. Event-Driven Ansible

Fixed a bug where the Swagger API docs URL returned 404 error with trailing slash. (AAP-27417)
Fixed a bug where logs contained stack trace errors inappropriately. (AAP-23605)
Fixed a bug where the API returned error 500 instead of error 400 when a foreign key ID did not exist. (AAP-23105)
Fix a bug where the Git hash of a project could be empty. (AAP-21641)
Fixed a bug where an activation could fail at the start time due to authentication errors with Podman. (AAP-21067)
Fixed a bug where a project could not get imported if it contained a malformed rulebook. (AAP-20868)
Added EDA_CSRF_TRUSTED_ORIGINS, which can be set by user input or defined based on the allowed hostnames provided or determined by the installer as a default. (AAP-19319)
Redirected all Event-Driven Ansible traffic to /eda/ following UI changes that require the redirect. (AAP-18989)
Fixed target database for Event-Driven automation restore from backup. (AAP-17918)
Fixed the automation controller URL check when installing Event-Driven Ansible without a controller. (AAP-17249)
Fixed a bug when the membership operator failed in a condition applied to a previously saved event. (AAP-16663)
Fixed Event-Driven Ansible nginx configuration for custom HTTPS port. (AAP-16000)
Instead of the target service only, all Event-Driven Ansible services are enabled after installation is completed. The Event-Driven Ansible services will always start after the setup is complete. (AAP-15889)

7.4. Ansible Automation Platform Operator

Fixed Django REST Framework (DRF) browsable views. (AAP-25508)

Chapter 8. Ansible Automation Platform documentation

Red Hat Ansible Automation Platform 2.5 documentation includes significant feature updates as well as documentation enhancements and offers an improved user experience.

The following are documentation enhancements in Ansible Automation Platform 2.5:

The Setting up an automation controller token chapter that previously existed has been deprecated and replaced with the Setting up a Red Hat Ansible Automation Platform credential topic. As the Event-Driven Ansible controller is now integrated with centralized authentication and the Platform UI, this method simplifies the authentication process required for rulebook activations moving forward.
Documentation changes for 2.5 reflect terminology and product changes. Additionally, we have consolidated content into fewer documents.
The following table summarizes title changes for the 2.5 release.

Version 2.4 document title	Version 2.5 document title
Red Hat Ansible Automation Platform release notes	Release notes
NA	New: Using automation analytics
Red Hat Ansible Automation Platform planning guide	Planning your installation
Containerized Ansible Automation Platform installation guide (Technology Preview release)	Containerized installation (First Generally Available release)
Deploying the Ansible Automation Platform operator on OpenShift Container Platform	Installing on OpenShift Container Platform
Getting started with automation controller Getting started with automation hub Getting started with Event-Driven Ansible	New: Getting started with Ansible Automation Platform
Installing and configuring central authentication for the Ansible Automation Platform	Access management and authentication
Getting started with Ansible playbooks	Getting started with Ansible playbooks
Ansible Automation Platform operations guide	Operating Ansible Automation Platform
Ansible Automation Platform automation mesh for operator-based installation	Automation mesh for managed cloud or operator environments
Ansible Automation Platform automation mesh for VM-based installation	Automation mesh for VM environments
Performance considerations for operator-based installation	Performance considerations for operator environments
Ansible Automation Platform operator backup and recovery guide	Backup and recovery for operator environments
Troubleshooting Ansible Automation Platform	Troubleshooting Ansible Automation Platform
Ansible Automation Platform hardening guide	Not available for 2.5 release; to be published at a later date
automation controller user guide	Using automation execution
automation controller administration guide	Configuring automation execution
automation controller API overview	Automation execution API overview
automation controller API reference	Automation execution API reference
automation controller CLI reference	Automation execution CLI reference
Event-Driven Ansible user guide	Using automation decisions
Managing content in automation hub	- Managing automation content - Automation content API reference
Ansible security automation guide	Ansible security automation guide
Using the automation calculator Viewing reports about your Ansible automation environment Evaluating your automation controller job runs using the job explorer Planning your automation jobs using the automation savings planner	Using automation analytics
Ansible Automation Platform creator guide	Developing automation content
Automation content navigator creator guide	Using content navigator
Creating and consuming execution environments	Creating and using execution environments
Installing Ansible plug-ins for Red Hat Developer Hub	Installing Ansible plug-ins for Red Hat Developer Hub
Using Ansible plug-ins for Red Hat Developer Hub	Using Ansible plug-ins for Red Hat Developer Hub

Legal Notice

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.