Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Ansible Automation Platform preview release notes

Red Hat Ansible Automation Platform 2.next

Upcoming changes in Ansible Automation Platform

Red Hat Customer Content Services

Abstract

Red Hat is providing upcoming changes in Ansible Automation Platform so you can prepare your environment before the next release.

Chapter 1. Preview release notes to help you plan
Copy link

This document provides early access to information about upcoming changes deemed impactful enough to warrant extra notice. References to version numbers or features are subject to change. This document does not provide a comprehensive list of new features and changes planned for the next release.

Chapter 2. Summary of changes
Copy link

Note the following upcoming changes:

  • Supported upgrade paths
  • Event-Driven Ansible ansible.eda and ansible-rulebook changes
  • Bring-Your-Own-Knowledge (BYOK) for Ansible Lightspeed intelligent assistant
  • New required metrics service

Chapter 3. Supported upgrade paths
Copy link

To ensure a successful upgrade to the next version of the Ansible Automation Platform, you must follow one of the following supported upgrade paths:

  • AAP 2.4 to 2.6 to 2.7
  • AAP 2.5 to 2.6 to 2.7
  • AAP 2.6 to 2.7

Upgrading directly from Ansible Automation Platform 2.4 to 2.7 or 2.5 to 2.7 is not supported.

Important

If your current environment was installed via RPM, please note that in order to upgrade to AAP 2.7 you must migrate using another installation method. Follow the guidelines for migrating to a new topology. The RPM installer has been removed with the release of version 2.7.

4.1. New ansible-rulebook built-in modules
Copy link

The following event sources and event filters will be available as built-in modules in ansible-rulebook, and removed from ansible.collection.

The following is the list of new built-in modules:

  • eda.builtin.dashes_to_underscores (filter)
  • eda.builtin.generic (source)
  • eda.builtin.insert_hosts_to_meta (filter)
  • eda.builtin.json_filter (filter)
  • eda.builtin.normalize_keys (filter)
  • eda.builtin.pg_listener (source)
  • eda.builtin.range (source)
  • eda.builtin.webhook (source)

For backwards compatibility, these plugins remain available in the ansible.eda namespace and are automatically mapped to eda.builtin. However, they are no longer actively maintained in the ansible.eda collection. If you currently have rulebooks that use these filters or sources, update your rulebooks to use the eda.builtin namespace instead of the ansible.eda namespace.

The following list of event sources is being deprecated in ansible.eda collection and moving to the corresponding certified cloud collections. The DE-supported decision environments have been updated to incorporate amazon.aws and azure.azcollection. If you update the DE-supported decision environment, make sure to update your ansible-rulebooks namespace to refer to the updated namespace as mentioned below:

  • ansible.eda.aws_cloudtrail to amazon.aws.aws_cloudtrail
  • ansible.eda.aws_sqs_queue to amazon.aws.aws_sqs_queue
  • ansible.eda.azure_service_bus to azure.azcollection.azure_service_bus

The following list of event sources is being removed from the certified ansible.eda collection, will not be supported by Red Hat engineering, but they will have community maintenance, and are available as part of the community.eda collection. If you are using any of these filters, make sure to update your ansible-rulebooks to use the community.eda namespace, and you will need a custom decision environment in order to keep running your rulebooks.

You can also keep your existing rulebooks with an older version of DE-supported or DE-minimal, while you update your rulebooks.

  • ansible.eda.file to community.eda.file
  • ansible.eda.file_watch to community.eda.file_watch
  • ansible.eda.journald to community.eda.journald
  • ansible.eda.tick to use either eda.builtin.generic or eda.builtin.range
  • ansible.eda.url_check to community.eda.url_check

Ansible Lightspeed intelligent assistant uses retrieval-augmented generation (RAG) to provide contextual answers grounded in Red Hat Ansible Automation Platform (AAP) documentation. With the upcoming Bring Your Own Knowledge (BYOK) capability, administrators can extend the intelligent assistant’s knowledge by adding their organization’s own documentation, such as internal AAP policies, operational procedures, and best practices, into the RAG pipeline. When users ask the intelligent assistant a question, responses are informed by both the organization’s custom content and Red Hat’s AAP documentation, with organizational content taking priority when relevant.

BYOK is designed for both OpenShift Operator and containerized installer deployments of Ansible Automation Platform. Administrators build a custom knowledge image externally using provided tooling, import it into their AAP environment, and configure the intelligent assistant to use it. The image can be updated or replaced over time as organizational documentation evolves.

Chapter 6. New required metrics service
Copy link

The Metrics Service is now a mandatory component of the Ansible Automation Platform. It is treated as a core architectural requirement, similar to automation controller or platform gateway, and cannot be opted out of during the installation process. This service collects key usage data of Ansible Automation Platform.

To ensure a seamless "zero-config" experience for the majority of users, the installation program follows an opinionated placement strategy. The installation program will automatically select a default node (for example, the first platform gateway node) if not specified, though Ansible Automation Platform admins can explicitly define the [automationmetrics] inventory group. Note that this service requires a new database, so if external databases are going to be utilized in the deploy then those credentials need to be provided to the installation program.

Chapter 7. Deprecated features
Copy link

  • The ee-cloud-services execution environment in Managed Application on Azure
  • Python 3.11 and earlier versions are deprecated

Starting with the release of Ansible Automation Platform (AAP) 2.7, the ee-cloud-services execution environment will not be available in new deployments of Ansible Automation Platform on Microsoft Azure. Existing Ansible Automation Platform on Microsoft Azure customers are encouraged to transition their automation workflows to the ee-supported or build a new execution environment; the execution environment will remain until you choose to remove it.

7.1.2. Summary of support
Copy link

  • Existing Installs: Upgraded environments may retain ee-cloud-services for a limited grace period, but it is considered "End of Life."
  • Fresh Installs: ee-supported & ee-minimal are the only cloud-focused EE provided out of the box.
  • Event-Driven Ansible ansible.eda.noop is deprecated and there will not be a replacement.

Support for Python 3.11 and all earlier versions is being phased out across all Supported Execution Environments and Minimal Execution Environments. To ensure security compliance and access to the latest performance optimizations, users must migrate to Python 3.12 or higher.

7.2.1. Affected environments
Copy link

1. Supported Execution Environments

These environments typically include the full standard library and common pre-installed dependencies.

2. Minimal Execution Environments

These are stripped-down, security-hardened environments used for Custom EE’s.

7.2.2. Action required
Copy link

Audit custom-built binaries. Python 3.11 minimal layers will no longer receive security vulnerability (CVE) patches.

Recommendation: Move to the python:3.12+ or equivalent Minimal EE instance.

7.2.3. Why this is happening
Copy link

Python 3.12+ offers significant improvements that older environments cannot support, specifically:

  • Improved Error Messages: More precise tracebacks for faster debugging.
  • Performance: Advancements in the Faster CPython project.
  • Security: Removal of deprecated APIs and older TLS versions that are increasingly vulnerable.

Chapter 8. Removed features
Copy link

  • Removal of direct component API access
  • Removal of RPM Installer in Ansible Automation Platform 2.7

8.1. Removal of direct component API access
Copy link

The next version of Ansible Automation Platform marks the completion of the platform unification initiative introduced in Ansible Automation Platform 2.5. With this release, the platform gateway becomes the sole entry point for all Ansible Automation Platform interactions, replacing direct API access to automation controller, automation hub, and Event-Driven Ansible.

This change centralizes organization management, authentication, and access control through a single, unified interface — providing a more consistent and secure experience across all automation capabilities within the platform.

Important

Any existing direct integrations with automation controller, automation hub, or Event-Driven Ansible APIs must be migrated to route through the platform gateway prior to upgrading to the next version of Ansible Automation Platform.

8.1.1. Previous compatibility support
Copy link

Ansible Automation Platform 2.5 and 2.6 maintained backward compatibility with pre-unification access patterns to provide a transition period for customers migrating to the unified platform. This compatibility layer is now removed. Integrations that continued to function through an upgrade from 2.4 to 2.6 will require remediation before upgrading.

8.1.2. Pre-upgrade migration assessment
Copy link

Before upgrading, review your environment for the following direct-access patterns, all of which require a migration plan:

Expand
AreaWhat to Review

User & Org Management

Any organization, team, or user management interfacing directly with automation controller or automation hub APIs or collections

Authentication

Legacy users authenticating with basic auth directly to automation controller

Tokens & OAuth

Legacy Personal Access Tokens (PATs) or OAuth applications connecting directly to automation controller

Image Management

Any container registry processes managing images directly on private automation hub

Access Control

RBAC configurations managed directly on individual components rather than through platform gateway

Job Management

Job template or job re-execution triggers to launch jobs directly to automation controller

Inventory Management

Managing Inventory using automation controller to add, edit, or remove inventory groups or nodes

Project Management

Managing SCM projects using automation controller to add, edit, or remove projects.

All of the above must be migrated to use the equivalent functionality provided by the platform gateway.

8.1.3. Direct access detection tooling
Copy link

To help you assess the scope of your migration effort, Red Hat has developed a tooling to identify legacy direct-access interactions across your Ansible Automation Platform deployment of 2.6 for containerized & operator based installations (additional details forthcoming).

In Ansible Automation Platform 2.5 release, the RPM installer was deprecated. Starting with Ansible Automation Platform 2.7, we are no longer providing the installer, and customers who have Ansible Automation Platform installed using RPM must migrate to either the containerised or Openshift Ansible Automation Platform Operator. Follow the guidelines for migrating to a new topology. Customers must first migrate to the new supported topology on the version that they are currently running (that is, Ansible Automation Platform 2.6 RPM to Ansible Automation Platform 2.6 containerised) before upgrading to Ansible Automation Platform 2.7.

Legal Notice
Copy link

Copyright © Red Hat.
Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . 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, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.
The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top