Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Planning your upgrade

Red Hat Ansible Automation Platform 2.6

Planning for a successful upgrade of Ansible Automation Platform

Red Hat Customer Content Services

Abstract

This guide provides a detailed overview of the changes and improvements in the upgrade process from Ansible Automation Platform 2.4 to 2.6, including new infrastructure requirements, data migration specifics, and a comparison of different deployment types. It addresses frequently asked questions and outlines how existing authentication and user data are handled during the upgrade.

Preface
Copy link

Use this guide to upgrade from Ansible Automation Platform 2.4 to 2.6. This documentation covers new infrastructure requirements, details how to handle user and authentication data, and provides guidance on various deployment scenarios to help you successfully plan your upgrade.

Providing feedback on Red Hat documentation
Copy link

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 upgrade improvements
Copy link

1.1. Overview of upgrade improvements
Copy link

Ansible Automation Platform 2.6 includes changes that significantly improve the upgrade experience when moving from Ansible Automation Platform 2.4 to 2.6.

Note

You must be on the latest version of 2.4 or 2.5 before you upgrade to 2.6.

Expand
ScenarioChangesAdditional information

Upgrading from 2.5 to 2.6

Upgrading from 2.5 to 2.6 does not involve changes to the platform infrastructure requirements, architecture, or services. The improvements described in the 2.4 to 2.6 upgrade path are also present in the 2.5 to 2.6 upgrade path; however, the platform gateway service is already in place in 2.5.

If you upgraded from 2.4 to 2.5, you must migrate your authentication methods and users before upgrading to 2.6 as that legacy authenticator functionality was removed.

Any users that were created during the 2.4 to 2.5 upgrade that were not fully migrated will be removed from the system when upgrading to 2.6. The users that have previously merged their user records while on 2.5 will continue to function as is for 2.6.

Any 2.4 automation controller users that have not successfully logged into 2.5 since upgrading from 2.4, will be unable to log into Ansible Automation Platform UI after upgrading to 2.6. The user will be backwards compatible for direct automation execution access but unable to access the full platform. Please ensure all users planning to leverage 2.6 have successfully logged into 2.5 prior to upgrading.

Note: Upgrades from the latest 2.5 version to 2.6 are supported with all deployment types: RPM, containerized, and OpenShift Container Platform deployments.

See the upgrade document for your deployment type:

Upgrading from 2.4 to 2.6

Ansible Automation Platform supports upgrading directly from the latest 2.4 version to 2.6. Directly upgrading to 2.6 is the recommended upgrade path from 2.4, as a number of improvements in 2.6 simplify and improve the upgrade experience.

Note: You can upgrade directly from the latest 2.4 version to 2.6 with RPM and OpenShift Container Platform deployments. However, upgrading Event-Driven Ansible 2.4 or from the 2.4 containerized deployment is not supported, as both features were Tech Preview in 2.4.

See the upgrade document for your deployment type:

 

Ansible Automation Platform RPM deployments require additional infrastructure compared with 2.4, due to the addition of the platform gateway service. Infrastructure needs vary depending on factors such as whether you implement a growth or an enterprise deployment.

Note: Additional infrastructure requirements apply only when upgrading RPM deployments.

See Infrastructure changes for details about infrastructure and inventory file changes in various upgrade scenarios.

 

Enterprise authentication configuration and mappings (for example, SAML, LDAP, OIDC) move from automation controller 2.4 to platform gateway 2.6 as part of the upgrade process. You do not need to manually reconfigure these authentication methods after you upgrade.

Note: Authentication upgrade improvements apply to RPM and OpenShift Container Platform deployments. Upgrades from the 2.4 containerized deployment Tech Preview release are not supported. Additionally, upgrading Event-Driven Ansible 2.4 is not supported.

See Access management and authentication for information about authentication options in general.

 

All automation controller Identity Access Management (IAM) data moves from automation controller 2.4 to the platform gateway in 2.6 as part of the upgrade process. With automation controller 2.4 as the default source of IAM data for the platform gateway in 2.6, users retain their memberships and are assigned appropriate platform-level roles in 2.6.

As part of the upgrade process:

  • Users, teams, organizations, their memberships, and common roles in 2.4 move from automation controller 2.4 to the platform gateway in 2.6.
  • Administrators in automation controller 2.4 become platform gateway administrators in 2.6.
  • Controller admins in 2.4 become platform gateway admins in 2.6.

The more organizations, teams, and users being migrated during an upgrade, the longer the upgrade takes. As an example, upgrading and migrating 4,000 users, 400 teams, and 40 organizations may take close to two hours.

Note: Identity access management changes apply to RPM and OpenShift Container Platform deployments. Upgrades from the 2.4 containerized deployment Tech Preview release are not supported.

See Data movement during upgrade for more information.

 

Some APIs are being deprecated in 2.6.

See API changes for more information.

Upgrading from 2.5 to 2.6 and upgrading from 2.4 to 2.6

All Ansible Automation Platform collections, which support the Configuration-as-Code (CaC) approach, now use a standard global environment variable name and module variable name across Ansible Automation Platform components. For more details, see What’s new around RBAC in 2.6 and What’s changed around RBAC for users moving from 2.5 to 2.6

See the documentation for ansible.platform in automation hub for more information.

Chapter 2. FAQs related to upgrading
Copy link

What are the supported installation topologies and operating systems for Ansible Automation Platform 2.6?

Red Hat has adopted a more definitive approach to installation topologies, categorizing them as "growth" or "enterprise" for production-ready setups:

  • Growth topology: is intended for organizations that are getting started with Ansible Automation Platform and do not require redundancy or higher compute for large volumes of automation.
  • Enterprise topology: is intended for organizations that require Ansible Automation Platform to be deployed with redundancy or higher compute for large volumes of automation.

For more information, see Tested deployment models.

Which Red Hat Enterprise Linux versions are supported for RPM and containerized installations?
RPM installations will continue to be supported exclusively on Red Hat Enterprise Linux 9. Containerized installations support both Red Hat Enterprise Linux 9.4 or later versions of Red Hat Enterprise Linux 9 and Red Hat Enterprise Linux 10 or later versions of Red Hat Enterprise Linux 10 for enterprise topologies.
What is the difference between "upgrade" and "migration" in Ansible Automation Platform 2.6?
An upgrade is an application action, such as updating Ansible Automation Platform 2.5 to 2.6. A migration involves moving data, such as from an RPM-based 2.6 installation to a container-based 2.6 installation. New service components are not explicitly required between versions 2.5 and 2.6.
Can I upgrade from 2.4 to 2.6 or must I upgrade to 2.5 first?
Yes you can upgrade directly to 2.6. However note that there may be new system requirements you must update before upgrading.
How will managed cloud customers be upgraded to Ansible Automation Platform 2.6?
All managed cloud customers on Microsoft Azure and Amazon Web Services will be upgraded to 2.6. Two upgrade window options will be available following the platform upgrade: non-production or production environments. Communications will be ongoing from mid-July until late September.
Will migrations be fully supported in Ansible Automation Platform 2.6?
Yes, migrations are fully supported, enabling customers to transition from RPM installations to containerized or OpenShift Container Platform environments, or to the managed offering. Customers must be on the latest version of Ansible Automation Platform for their current installation prior to migrating. The installer will manage new components introduced in version 2.5 for direct 2.4 to 2.6 upgrades.
I’m using Event-Driven Ansible in 2.4, can I upgrade Event-Driven Ansible to 2.6?
If you are using Ansible Automation Platform 2.4 with the technical preview of Event-Driven Ansible controller but want to upgrade to the Ansible Automation Platform 2.6 with Event-Driven Ansible, you must install a new instance of Ansible Automation Platform 2.6 and manually re-create your Event-Driven Ansible configurations in the new, fully integrated environment.
Will my existing 2.4 or 2.5 OAuth Applications/Tokens, Credentials/Customer Credentials, and Personal Access Tokens still work after upgrading to 2.6?

For upgrades from Ansible Automation Platform 2.4 or 2.5 to Ansible Automation Platform 2.6, some manual configuration is required:

  • OAuth applications:

    • Automation controller: You can view and edit existing automation controller applications, but you cannot create new ones. They still function, but they might be removed in a future release. You should plan to migrate to platform OAuth applications.
    • Ansible Automation Platform: Platform OAuth applications provide an updated interface and are the standard for future use. You will transition to these applications.

  • Tokens:

    • Automation controller: Automation controller personal access tokens (PATs) are deprecated. You will move to platform gateway PATs.
    • Ansible Automation Platform: Platform tokens provide an updated interface and are the standard for future use. You will transition to these tokens.

  • Authenticator configurations:

    • Ansible Automation Platform 2.4 to Ansible Automation Platform 2.6: The migration of all authenticator configurations from the automation controller to the platform gateway is automated. This includes third-party authentication configurations and sensitive data like SAML private keys or OAuth secret keys. If you use custom LDAP certificates, you must manually migrate them.
    • Ansible Automation Platform 2.5 to Ansible Automation Platform 2.6: Authenticator configurations are not automatically migrated. LDAP settings configured in Ansible Automation Platform 2.5 remain as they were after upgrading to 2.6.
What RBAC (platform gateway and/or automation controller) control permissions will be missing in version 2.6?
  • For 2.4 to 2.6 upgrades: During the upgrade, authenticators and their mappings from the controller are imported into the gateway; therefore, you don’t need to manually migrate authenticators.
  • For 2.5 to 2.6 upgrades: Authenticators and their mappings in the platform gateway continue to function as is, because no changes are imported.
Which version of PostgreSQL does Ansible Automation Platform 2.6 support?
Ansible Automation Platform 2.6 supports PostgreSQL 15 for its managed databases and additionally supports PostgreSQL 15, 16, and 17 for external databases.

Chapter 3. Support matrix for upgrade scenarios
Copy link

Determine which upgrade paths are supported for your current Ansible Automation Platform deployment. The following reference tables show RHEL version compatibility and give step-by-step upgrade processes organized by deployment type: RPM-based, container-based, and OpenShift Container Platform deployments.

Note

In-place upgrades of major RHEL versions are not supported. You must migrate your existing deployment of Ansible Automation Platform to a new RHEL environment.

3.1. Supported RHEL versions by deployment type
Copy link

Supported RHEL versions differ among deployment types, as shown in the following table.

Expand
Deployment type and versionSupported RHEL version

RPM 2.6

RHEL 9

Containerized 2.6

RHEL 9, RHEL 10

OpenShift Container Platform 2.6

For RHEL versions included with OpenShift Container Platform, see Red Hat OpenShift Container Platform Life Cycle Policy.

3.2. RPM-based upgrade scenarios
Copy link

Use the following reference tables to find the supported upgrade paths for RPM-based deployments of Ansible Automation Platform.

Expand
SourceTargetProcess

RPM-based Ansible Automation Platform 2.4 on RHEL 8

RPM-based Ansible Automation Platform 2.6 on RHEL 9

  1. Backup your deployment of 2.4 RPM on RHEL 8, then restore to a RHEL 9 environment running a fresh installation of RPM 2.4.
  2. Upgrade your RPM deployment from 2.4 to 2.6.

RPM-based Ansible Automation Platform 2.4 on RHEL 8

Container-based Ansible Automation Platform 2.6 on RHEL 9

  1. Backup your deployment of 2.4 RPM on RHEL 8, then restore to a RHEL 9 environment running a fresh installation of RPM 2.4.
  2. Upgrade your RPM deployment from 2.4 to 2.6.
  3. Migrate your RPM deployment 2.6 to a container deployment 2.6.

RPM-based Ansible Automation Platform 2.4 on RHEL 8

Container-based Ansible Automation Platform 2.6 on RHEL 10

  1. Backup your deployment of 2.4 RPM on RHEL 8, then restore to a RHEL 9 environment running a fresh installation of RPM 2.4.
  2. Upgrade your RPM deployment from 2.4 to 2.6.
  3. Migrate your RPM deployment 2.6 to a container deployment 2.6.
  4. Backup your deployment of container 2.6 on RHEL 9, then restore to a RHEL 10 environment running a fresh container installation 2.6.

RPM-based Ansible Automation Platform 2.4 on RHEL 8

Ansible Automation Platform on OpenShift Container Platform 2.6

  1. Backup your deployment of 2.4 RPM on RHEL 8, then restore to a RHEL 9 environment running a fresh installation of RPM 2.4.
  2. Upgrade your RPM deployment from 2.4 to 2.6.
  3. Migrate your RPM deployment 2.6 to Ansible Automation Platform on OpenShift Container Platform 2.6.
Expand
SourceTargetProcess

RPM-based Ansible Automation Platform 2.4 on RHEL 9

RPM-based Ansible Automation Platform 2.6 on RHEL 9

  1. Upgrade your RPM deployment from 2.4 to 2.6.

RPM-based Ansible Automation Platform 2.4 on RHEL 9

Container-based Ansible Automation Platform 2.6 on RHEL 9

  1. Upgrade your RPM deployment from 2.4 to 2.6.
  2. Migrate your RPM deployment 2.6 to a container deployment 2.6.

RPM-based Ansible Automation Platform 2.4 on RHEL 9

Container-based Ansible Automation Platform 2.6 on RHEL 10

  1. Upgrade your RPM deployment from 2.4 to 2.6.
  2. Migrate your RPM deployment 2.6 to a container deployment 2.6.
  3. Backup your deployment of container 2.6 on RHEL 9, then restore to a RHEL 10 environment running a fresh container installation 2.6.

RPM-based Ansible Automation Platform 2.4 on RHEL 9

Ansible Automation Platform on OpenShift Container Platform 2.6

  1. Upgrade your RPM deployment from 2.4 to 2.6.
  2. Migrate your RPM deployment 2.6 to Ansible Automation Platform on OpenShift Container Platform 2.6.
Expand
SourceTargetProcess

RPM-based Ansible Automation Platform 2.5 on RHEL 8

RPM-based Ansible Automation Platform 2.6 on RHEL 9

  1. Backup your deployment of 2.5 RPM on RHEL 8, then restore to a RHEL 9 environment running a fresh installation of RPM 2.5.
  2. Upgrade your RPM deployment from 2.5 to 2.6.

RPM-based Ansible Automation Platform 2.5 on RHEL 8

Container-based Ansible Automation Platform 2.6 on RHEL 9

  1. Backup your deployment of 2.5 RPM on RHEL 8, then restore to a RHEL 9 environment running a fresh installation of RPM 2.5.
  2. Upgrade your RPM deployment from 2.5 to 2.6.
  3. Migrate your RPM deployment 2.6 to a container deployment 2.6.

RPM-based Ansible Automation Platform 2.5 on RHEL 8

Container-based Ansible Automation Platform 2.6 on RHEL 10

  1. Backup your deployment of 2.5 RPM on RHEL 8, then restore to a RHEL 9 environment running a fresh installation of RPM 2.5.
  2. Upgrade your RPM deployment from 2.5 to 2.6.
  3. Migrate your RPM deployment 2.6 to a container deployment 2.6.
  4. Backup your deployment of container 2.6 on RHEL 9, then restore to a RHEL 10 environment running a fresh container installation 2.6.

RPM-based Ansible Automation Platform 2.5 on RHEL 8

Ansible Automation Platform on OpenShift Container Platform 2.6

  1. Backup your deployment of 2.5 RPM on RHEL 8, then restore to a RHEL 9 environment running a fresh installation of RPM 2.5.
  2. Upgrade your RPM deployment from 2.5 to 2.6.
  3. Migrate your RPM deployment 2.6 to Ansible Automation Platform on OpenShift Container Platform 2.6.
Expand
SourceTargetProcess

RPM-based Ansible Automation Platform 2.5 on RHEL 9

RPM-based Ansible Automation Platform 2.6 on RHEL 9

RPM-based Ansible Automation Platform 2.5 on RHEL 9

Container-based Ansible Automation Platform 2.6 on RHEL 9

  1. Upgrade your RPM deployment from 2.5 to 2.6.
  2. Migrate your RPM deployment 2.6 to a container deployment 2.6.

RPM-based Ansible Automation Platform 2.5 on RHEL 9

Container-based Ansible Automation Platform 2.6 on RHEL 10

  1. Upgrade your RPM deployment from 2.5 to 2.6.
  2. Migrate your RPM deployment 2.6 to a container deployment 2.6.
  3. Backup your deployment of container 2.6 on RHEL 9, then restore to a RHEL 10 environment running a fresh container installation 2.6.

RPM-based Ansible Automation Platform 2.5 on RHEL 9

Ansible Automation Platform on OpenShift Container Platform 2.6

  1. Upgrade your RPM deployment from 2.5 to 2.6.
  2. Migrate your RPM deployment 2.6 to Ansible Automation Platform on OpenShift Container Platform 2.6.
Expand
SourceTargetProcess

RPM-based Ansible Automation Platform 2.6 on RHEL 9

Container-based Ansible Automation Platform 2.6 on RHEL 10

  1. Migrate your RPM deployment 2.6 to a container deployment 2.6.
  2. Backup your deployment of container 2.6 on RHEL 9, then restore to a RHEL 10 environment running a fresh container installation 2.6.

RPM-based Ansible Automation Platform 2.6 on RHEL 9

Ansible Automation Platform on OpenShift Container Platform 2.6

3.3. Container-based upgrade scenarios
Copy link

Use the following reference tables to find the supported upgrade paths for container-based deployments of Ansible Automation Platform.

Expand
SourceTargetProcess

Container-based Ansible Automation Platform 2.5 on RHEL 9

Container-based Ansible Automation Platform 2.6 on RHEL 9

Container-based Ansible Automation Platform 2.5 on RHEL 9

Container-based Ansible Automation Platform 2.6 on RHEL 10

  1. Backup your container deployment of 2.5 on a RHEL 9 environment, then restore to a RHEL 10 environment running a fresh container installation 2.5.
  2. Upgrade your container deployment from 2.5 to 2.6.

Container-based Ansible Automation Platform 2.5 on RHEL 9

Ansible Automation Platform on OpenShift Container Platform 2.6

  1. Upgrade your container deployment from 2.5 to 2.6.
  2. Migrate your container deployment 2.6 to Ansible Automation Platform on OpenShift Container Platform 2.6.
Expand
SourceTargetProcess

Container-based Ansible Automation Platform 2.5 on RHEL 10

Container-based Ansible Automation Platform 2.6 on RHEL 10

Container-based Ansible Automation Platform 2.5 on RHEL 10

Ansible Automation Platform on OpenShift Container Platform 2.6

  1. Upgrade your container deployment from 2.5 to 2.6.
  2. Migrate your container deployment 2.6 to Ansible Automation Platform on OpenShift Container Platform 2.6.
Expand
SourceTargetProcess

Container-based Ansible Automation Platform 2.6 on RHEL 9

Container-based Ansible Automation Platform 2.6 on RHEL 10

Container-based Ansible Automation Platform 2.6 on RHEL 9

Ansible Automation Platform on OpenShift Container Platform 2.6

Expand
SourceTargetProcess

Container-based Ansible Automation Platform 2.6 on RHEL 10

Ansible Automation Platform on OpenShift Container Platform 2.6

Use the following reference tables to find the supported upgrade paths for Ansible Automation Platform deployments on OpenShift Container Platform.

Expand
SourceTargetProcess

Ansible Automation Platform on OpenShift Container Platform 2.4

Ansible Automation Platform on OpenShift Container Platform 2.6

Expand
SourceTargetProcess

Ansible Automation Platform on OpenShift Container Platform 2.5

Ansible Automation Platform on OpenShift Container Platform 2.6

Expand
SourceTargetProcess

Ansible Automation Platform on OpenShift Container Platform 2.6

Container-based Ansible Automation Platform 2.6 on RHEL 10

You can review the infrastructure changes required when upgrading to Ansible Automation Platform 2.6. The infrastructure changes vary depending on your current version, deployment method, and target topology.

  • RPM and Operator-based deployments: Upgrade directly from version 2.4 or 2.5 to 2.6
  • Container-based deployments: Upgrade from version 2.5 to 2.6 (upgrades from 2.4 are not supported)

Each deployment type section includes topology diagrams, infrastructure requirements, and configuration examples to help you plan your upgrade.

4.1. RPM-based deployments
Copy link

The following sections describe the tested infrastructure changes for RPM-based deployments. For step-by-step upgrade instructions, see RPM upgrade.

You can upgrade your 2.4 single automation controller node deployment to a 2.6 growth topology. This section outlines the infrastructure changes, requirements, and an example inventory for upgrading.

4.1.1.1. 2.4 infrastructure topology diagram
Copy link

This diagram outlines the 2.4 infrastructure topology for this deployment model.

Figure 4.1. 2.4 infrastructure topology diagram

2.4 single controller topology
View larger image
2.4 single controller topology
4.1.1.2. 2.6 infrastructure topology diagram
Copy link

This diagram outlines the 2.6 infrastructure topology that Red Hat has tested with this deployment model.

Figure 4.2. 2.6 infrastructure topology diagram

2.6 single controller growth topology
View larger image
2.6 single controller growth topology

The following table highlights the requirements for upgrading from Ansible Automation Platform version 2.4 to 2.6.

Expand
Existing 2.4 topologyTested 2.6 topologyRequirements for each VM

Non-redundant automation controller-only deployment:

  • One automation controller virtual machine (VM)
  • One Ansible Automation Platform managed PostgreSQL 15 database

Growth topology:

  • One platform gateway with colocated Redis VM
  • One automation controller VM
  • One private automation hub VM
  • One Event-Driven Ansible controller VM
  • One automation mesh execution node
  • One Ansible Automation Platform managed PostgreSQL 15 database

See the RPM growth topology section of the Tested deployment models guide.

4.1.1.4. Example inventory file
Copy link

The following inventory file has been updated with the necessary changes to upgrade to the 2.6 growth topology. 

# This is the RPM-based Ansible Automation Platform installer inventory file intended for upgrading from a 2.4 single automation controller deployment to a 2.6 growth deployment.
# Consult the Ansible Automation Platform product documentation about this topology's tested hardware configuration.
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/tested_deployment_models/rpm-topologies
# For all optional variables consult the Ansible Automation Platform documentation:
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation

# This section is for your platform gateway hosts - NEW for 2.6 growth topology
# -----------------------------------------------------
[automationgateway]
gateway.example.org

# This section is for your automation controller hosts from your 2.4 inventory
# -----------------------------------------------------
[automationcontroller]
controller.example.org

[automationcontroller:vars]
peers=execution_nodes

# This section is for your execution hosts - NEW for 2.6 growth topology
# -----------------------------------------------------
[execution_nodes]
exec.example.org

# This section is for your automation hub hosts - NEW for 2.6 growth topology
# -----------------------------------------------------
[automationhub]
hub.example.org

# This section is for your Event-Driven Ansible hosts - NEW for 2.6 growth topology
# -----------------------------------------------------
[automationedacontroller]
eda.example.org

# This section is for the Ansible Automation Platform database from your 2.4 inventory file
# -----------------------------------------------------
[database]
db.example.org

[all:vars]

# Common variables from your 2.4 inventory file
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#general-variables
# -----------------------------------------------------
registry_username=<your RHN username>
registry_password=<your RHN password>

# Common variables - NEW for 2.6 growth topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#general-variables
# -----------------------------------------------------
redis_mode=standalone

# Platform gateway - NEW for 2.6 growth topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#platform-gateway-variables
# -----------------------------------------------------
automationgateway_admin_password=<set your own>
automationgateway_pg_host=db.example.org
automationgateway_pg_password=<set your own>

# Automation controller variables from your 2.4 inventory file
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#controller-variables
# -----------------------------------------------------
admin_password=<set your own>
pg_host=db.example.org
pg_password=<set your own>

# Automation hub - NEW for 2.6 growth topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#hub-variables
# -----------------------------------------------------
automationhub_admin_password=<set your own>
automationhub_pg_host=db.example.org
automationhub_pg_password=<set your own>

# Event-Driven Ansible - NEW for 2.6 growth topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#event-driven-ansible-variables
# -----------------------------------------------------
automationedacontroller_admin_password=<set your own>
automationedacontroller_pg_host=db.example.org
automationedacontroller_pg_password=<set your own>
Copy to Clipboard Toggle word wrap

You can upgrade your 2.4 single node automation controller and automation hub deployment to a 2.6 growth topology. This section outlines the infrastructure changes, requirements, and an example inventory for upgrading.

4.1.2.1. 2.4 infrastructure topology diagram
Copy link

This diagram outlines the 2.4 infrastructure topology for this deployment model.

Figure 4.3. 2.4 infrastructure topology diagram

2.4 single controller and hub topology
View larger image
2.4 single controller and hub topology
4.1.2.2. 2.6 infrastructure topology diagram
Copy link

This diagram outlines the 2.6 infrastructure topology that Red Hat has tested with this deployment model.

Figure 4.4. 2.6 infrastructure topology diagram

2.6 single controller and hub growth topology
View larger image
2.6 single controller and hub growth topology

The following table highlights the requirements for upgrading from Ansible Automation Platform version 2.4 to 2.6.

Expand
Existing 2.4 topologyTested 2.6 topologyRequirements for each VM

Non-redundant deployment with automation controller and automation hub:

  • One automation controller VM
  • One automation hub VM
  • One Ansible Automation Platform managed PostgreSQL 15 database

Growth topology:

  • One platform gateway with colocated Redis VM
  • One automation controller VM
  • One private automation hub VM
  • One Event-Driven Ansible controller VM
  • One automation mesh execution node
  • One Ansible Automation Platform managed PostgreSQL 15 database

See the RPM growth topology section of the Tested deployment models guide.

4.1.2.4. Example inventory file
Copy link

The following inventory file has been updated with the necessary changes to upgrade to the 2.6 growth topology. 

# This is the RPM-based Ansible Automation Platform installer inventory file intended for upgrading from a 2.4 single automation controller and automation hub deployment to a 2.6 growth deployment.

# Consult the Ansible Automation Platform product documentation about this topology's tested hardware configuration.
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/tested_deployment_models/rpm-topologies
# For all optional variables consult the Ansible Automation Platform documentation:
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation

# This section is for your platform gateway hosts - NEW for 2.6 growth topology
# -----------------------------------------------------
[automationgateway]
gateway.example.org

# This section is for your automation controller hosts from your 2.4 inventory
# -----------------------------------------------------
[automationcontroller]
controller.example.org

[automationcontroller:vars]
peers=execution_nodes

# This section is for your execution hosts - NEW for 2.6 growth topology
# -----------------------------------------------------
[execution_nodes]
exec.example.org

# This section is for your automation hub hosts from your 2.4 inventory
# -----------------------------------------------------
[automationhub]
hub.example.org

# This section is for your Event-Driven Ansible hosts - NEW for 2.6 growth topology
# -----------------------------------------------------
[automationedacontroller]
eda.example.org

# This section is for the Ansible Automation Platform database from your 2.4 inventory file
# -----------------------------------------------------
[database]
db.example.org

[all:vars]

# Common variables from your 2.4 inventory file
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#general-variables
# -----------------------------------------------------
registry_username=<your RHN username>
registry_password=<your RHN password>

# Common variables - NEW for 2.6 growth topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#general-variables
# -----------------------------------------------------
redis_mode=standalone

# Platform gateway - NEW for 2.6 growth topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#platform-gateway-variables
# -----------------------------------------------------
automationgateway_admin_password=<set your own>
automationgateway_pg_host=db.example.org
automationgateway_pg_password=<set your own>

# Automation controller variables from your 2.4 inventory file
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#controller-variables
# -----------------------------------------------------
admin_password=<set your own>
pg_host=db.example.org
pg_password=<set your own>

# Automation hub - NEW for 2.6 growth topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#hub-variables
# -----------------------------------------------------
automationhub_admin_password=<set your own>
automationhub_pg_host=db.example.org
automationhub_pg_password=<set your own>

# Event-Driven Ansible - NEW for 2.6 growth topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#event-driven-ansible-variables
# -----------------------------------------------------
automationedacontroller_admin_password=<set your own>
automationedacontroller_pg_host=db.example.org
automationedacontroller_pg_password=<set your own>
Copy to Clipboard Toggle word wrap

You can upgrade your 2.4 multi node automation controller deployment to a 2.6 enterprise topology. This section outlines the infrastructure changes, requirements, and an example inventory for upgrading.

4.1.3.1. 2.4 infrastructure topology diagram
Copy link

This diagram outlines the 2.4 infrastructure topology for this deployment model.

Figure 4.5. 2.4 infrastructure topology diagram

2.4 multi controller topology
View larger image
2.4 multi controller topology
4.1.3.2. 2.6 infrastructure topology diagram
Copy link

This diagram outlines the 2.6 infrastructure topology that Red Hat has tested with this deployment model.

Figure 4.6. 2.6 infrastructure topology diagram

2.6 multi controller enterprise topology
View larger image
2.6 multi controller enterprise topology

The following table highlights the requirements for upgrading from Ansible Automation Platform version 2.4 to 2.6.

Expand
Existing 2.4 topologyTested 2.6 topologyRequirements for each VM

Redundant automation controller-only deployment:

  • Two automation controller VMs
  • One automation mesh hop node VM
  • Two automation mesh execution node VMs
  • One customer-provided (external) PostgreSQL 15 database
  • One HA proxy load balancer in front of automation controller

Enterprise topology:

  • Two platform gateway with colocated Redis VMs
  • Two automation controller VMs
  • Two private automation hub with colocated Redis VMs
  • Two Event-Driven Ansible controller with colocated Redis VMs
  • One automation mesh hop node VM
  • Two automation mesh execution node VMs
  • One customer-provided (external) PostgreSQL 15 database
  • One HA proxy load balancer in front of platform gateway

Note: Redis high availability requires 6 VMs. Redis can be colocated with automation hub, platform gateway, or Event-Driven Ansible components, but it cannot be colocated with automation controller, execution nodes, or the PostgreSQL database.

See the RPM enterprise topology section of the Tested deployment models guide.

4.1.3.4. Example inventory file
Copy link

The following inventory file has been updated with the necessary changes to upgrade to the 2.6 enterprise topology. 

# This is the RPM-based Ansible Automation Platform installer inventory file intended for upgrading from a 2.4 multi node automation controller deployment to a 2.6 enterprise deployment.

# For all optional variables consult the Red Hat documentation:
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation

# This section is for your platform gateway hosts - NEW for 2.6 enterprise topology
# -----------------------------------------------------
[automationgateway]
gateway1.example.org
gateway2.example.org

# This section is for your automation controller hosts from your 2.4 inventory
# -----------------------------------------------------
[automationcontroller]
controller1.example.org
controller2.example.org

[automationcontroller:vars]
peers=execution_nodes

# This section is for your execution hosts from your 2.4 inventory
# -----------------------------------------------------
[execution_nodes]
hop1.example.org node_type='hop'
exec1.example.org
exec2.example.org

# This section is for your automation hub hosts - NEW for 2.6 enterprise topology
# -----------------------------------------------------
[automationhub]
hub1.example.org
hub2.example.org

# This section is for your Event-Driven Ansible hosts - NEW for 2.6 enterprise topology
# -----------------------------------------------------
[automationedacontroller]
eda1.example.org
eda2.example.org

# This section is for your Redis hosts - NEW for 2.6 enterprise topology
# -----------------------------------------------------
[redis]
gateway1.example.org
gateway2.example.org
hub1.example.org
hub2.example.org
eda1.example.org
eda2.example.org

[all:vars]
# Common variables from your 2.4 inventory
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#general-variables
# -----------------------------------------------------
registry_username=<your RHN username>
registry_password=<your RHN password>

# Platform gateway - NEW for 2.6 enterprise topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#platform-gateway-variables
# -----------------------------------------------------
automationgateway_admin_password=<set your own>
automationgateway_main_url=<set your own> #Set to the URL of the load balancer
automationgateway_pg_host=<set your own>
automationgateway_pg_database=<set your own>
automationgateway_pg_username=<set your own>
automationgateway_pg_password=<set your own>

# Automation controller variables from your 2.4 inventory
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#controller-variables
# -----------------------------------------------------
admin_password=<set your own>
pg_host=<set your own>
pg_database=<set your own>
pg_username=<set your own>
pg_password=<set your own>

# Automation hub - NEW for 2.6 enterprise topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#hub-variables
# -----------------------------------------------------
automationhub_admin_password=<set your own>
automationhub_pg_host=<set your own>
automationhub_pg_database=<set your own>
automationhub_pg_username=<set your own>
automationhub_pg_password=<set your own>

# Event-Driven Ansible - NEW for 2.6 enterprise topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#event-driven-ansible-variables
# -----------------------------------------------------
automationedacontroller_admin_password=<set your own>
automationedacontroller_pg_host=<set your own>
automationedacontroller_pg_database=<set your own>
automationedacontroller_pg_username=<set your own>
automationedacontroller_pg_password=<set your own>
Copy to Clipboard Toggle word wrap

You can upgrade your 2.4 multi node automation controller and automation hub deployment to a 2.6 enterprise topology. This section outlines the infrastructure changes, requirements, and an example inventory for upgrading.

4.1.4.1. 2.4 infrastructure topology diagram
Copy link

This diagram outlines the 2.4 infrastructure topology that Red Hat has tested with this deployment model.

Figure 4.7. 2.4 infrastructure topology diagram

2.4 multi controller and hub topology
View larger image
2.4 multi controller and hub topology
4.1.4.2. 2.6 infrastructure topology diagram
Copy link

This diagram outlines the 2.6 infrastructure topology that Red Hat has tested with this deployment model.

Figure 4.8. 2.6 infrastructure topology diagram

2.6 multi controller and hub enterprise topology
View larger image
2.6 multi controller and hub enterprise topology

The following table highlights the requirements for upgrading from Ansible Automation Platform version 2.4 to 2.6.

Expand
Existing 2.4 topologyTested 2.6 topologyRequirements for each VM

Redundant deployment with automation controller and automation hub:

  • Two automation controller VMs
  • Two automation hub VMs
  • One automation mesh hop node VM
  • Two automation mesh execution node VMs
  • One customer-provided (external) PostgreSQL 15 database
  • One HA proxy load balancer in front of automation controller and automation hub

Enterprise topology:

  • Two platform gateway with colocated Redis VMs
  • Two automation controller VMs
  • Two private automation hub with colocated Redis VMs
  • Two Event-Driven Ansible controller with colocated Redis VMs
  • One automation mesh hop node VM
  • Two automation mesh execution node VMs
  • One customer-provided (external) PostgreSQL 15 database
  • One HA proxy load balancer in front of platform gateway

Note: Redis high availability requires 6 VMs. Redis can be colocated with automation hub, platform gateway, or Event-Driven Ansible components, but it cannot be colocated with automation controller, execution nodes, or the PostgreSQL database.

See the RPM enterprise topology section of the Tested deployment models guide.

4.1.4.4. Example inventory file
Copy link

The following inventory file has been updated with the necessary changes to upgrade to the 2.6 enterprise topology.

Important

If your 2.4 inventory file uses automationhub_main_url for a load balancer, you must remove this variable from your 2.6 inventory file. The load balancer is now expected to be configured in front of platform gateway (automationgateway_main_url). 

# This is the RPM-based Ansible Automation Platform installer inventory file intended for upgrading from a 2.4 multi node automation controller and automation hub deployment to a 2.6 enterprise deployment.

# For all optional variables consult the Red Hat documentation:
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation

# This section is for your platform gateway hosts - NEW for 2.6 enterprise topology
# -----------------------------------------------------
[automationgateway]
gateway1.example.org
gateway2.example.org

# This section is for your automation controller hosts from your 2.4 inventory
# -----------------------------------------------------
[automationcontroller]
controller1.example.org
controller2.example.org

[automationcontroller:vars]
peers=execution_nodes

# This section is for your execution hosts from your 2.4 inventory
# -----------------------------------------------------
[execution_nodes]
hop1.example.org node_type='hop'
exec1.example.org
exec2.example.org

# This section is for your automation hub hosts from your 2.4 inventory
# -----------------------------------------------------
[automationhub]
hub1.example.org
hub2.example.org

# This section is for your Event-Driven Ansible hosts - NEW for 2.6 enterprise topology
# -----------------------------------------------------
[automationedacontroller]
eda1.example.org
eda2.example.org

# This section is for your Redis hosts - NEW for 2.6 enterprise topology
# -----------------------------------------------------
[redis]
gateway1.example.org
gateway2.example.org
hub1.example.org
hub2.example.org
eda1.example.org
eda2.example.org

[all:vars]
# Common variables from your 2.4 inventory
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#general-variables
# -----------------------------------------------------
registry_username=<your RHN username>
registry_password=<your RHN password>

# Platform gateway - NEW for 2.6 enterprise topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#platform-gateway-variables
# -----------------------------------------------------
automationgateway_admin_password=<set your own>
automationgateway_main_url=<set your own> #Set to the URL of the load balancer
automationgateway_pg_host=<set your own>
automationgateway_pg_database=<set your own>
automationgateway_pg_username=<set your own>
automationgateway_pg_password=<set your own>

# Automation controller variables from your 2.4 inventory
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#controller-variables
# -----------------------------------------------------
admin_password=<set your own>
pg_host=<set your own>
pg_database=<set your own>
pg_username=<set your own>
pg_password=<set your own>

# Automation hub variables from your 2.4 inventory
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#hub-variables
# -----------------------------------------------------
automationhub_admin_password=<set your own>
automationhub_pg_host=<set your own>
automationhub_pg_database=<set your own>
automationhub_pg_username=<set your own>
automationhub_pg_password=<set your own>
# This variable is no longer used for load balancer configuration in 2.6:
# automationhub_main_url=<set your own>

# Event-Driven Ansible - NEW for 2.6 enterprise topology
# https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/rpm_installation/appendix-inventory-files-vars#event-driven-ansible-variables
# -----------------------------------------------------
automationedacontroller_admin_password=<set your own>
automationedacontroller_pg_host=<set your own>
automationedacontroller_pg_database=<set your own>
automationedacontroller_pg_username=<set your own>
automationedacontroller_pg_password=<set your own>
Copy to Clipboard Toggle word wrap

You can upgrade your 2.5 RPM-based growth topology to a 2.6 RPM-based growth topology. The topologies are the same between Ansible Automation Platform 2.5 and 2.6.

For more information about the growth topology infrastructure requirements and configuration details, see the RPM growth topology section of Tested deployment models.

You can upgrade your 2.5 RPM-based enterprise topology to a 2.6 RPM-based enterprise topology. The topologies are the same between Ansible Automation Platform 2.5 and 2.6.

For more information about the enterprise topology infrastructure requirements and configuration details, see the RPM enterprise topology section of Tested deployment models.

4.2. Container-based deployments
Copy link

The following sections describe the tested infrastructure changes for container-based deployments. For step-by-step upgrade instructions, see Updating containerized Ansible Automation Platform.

Note

Upgrades from Containerized Ansible Automation Platform 2.4 to 2.6 are not supported.

You can upgrade your 2.5 container-based growth topology to a 2.6 container-based growth topology. The topologies are the same between Ansible Automation Platform 2.5 and 2.6.

For more information about the growth topology infrastructure requirements and configuration details, see the Container growth topology section of Tested deployment models.

You can upgrade your 2.5 container-based enterprise topology to a 2.6 container-based enterprise topology. The topologies are the same between Ansible Automation Platform 2.5 and 2.6.

For more information about the enterprise topology infrastructure requirements and configuration details, see the Container enterprise topology section of Tested deployment models.

4.3. Operator-based deployments
Copy link

The following sections describe the tested infrastructure changes for Operator-based deployments. For step-by-step upgrade instructions, see Upgrading Red Hat Ansible Automation Platform Operator on Red Hat OpenShift Container Platform.

You can upgrade your 2.4 single automation controller node deployment to a 2.6 growth topology. This section outlines the infrastructure changes and requirements for upgrading.

4.3.1.1. 2.4 infrastructure topology diagram
Copy link

This diagram outlines the 2.4 infrastructure topology for this deployment model.

Figure 4.9. 2.4 infrastructure topology diagram

2.4 single controller topology
View larger image
2.4 single controller topology
4.3.1.2. 2.6 infrastructure topology diagram
Copy link

This diagram outlines the 2.6 infrastructure topology that Red Hat has tested with this deployment model.

Figure 4.10. 2.6 infrastructure topology diagram

2.6 growth topology
View larger image
2.6 growth topology

The following table highlights the requirements for upgrading from Ansible Automation Platform 2.4 to 2.6.

Expand
Existing 2.4 topologyTested 2.6 topologyRequirements for each pod

Non-redundant automation controller-only deployment:

  • One automation controller web pod
  • One automation controller task pod
  • One database pod

Growth topology:

  • One automation controller web pod
  • One automation controller task pod
  • One automation hub web pod
  • One automation hub API pod
  • Two automation hub content pods
  • Two automation hub worker pods
  • One automation hub Redis pod
  • One Event-Driven Ansible controller API pod
  • One Event-Driven Ansible controller activation worker pod
  • One Event-Driven Ansible controller default worker pod
  • One Event-Driven Ansible controller event stream pod
  • One Event-Driven Ansible controller scheduler pod
  • One platform gateway pod
  • One database pod
  • One Redis pod

See the Operator growth topology section of the Tested deployment models guide.

You can upgrade your 2.4 single automation controller and automation hub deployment to a 2.6 growth topology. This section outlines the infrastructure changes and requirements for upgrading.

4.3.2.1. 2.4 infrastructure topology diagram
Copy link

This diagram outlines the 2.4 infrastructure topology for this deployment model.

Figure 4.11. 2.4 infrastructure topology diagram

2.4 single controller and hub topology
View larger image
2.4 single controller and hub topology
4.3.2.2. 2.6 infrastructure topology diagram
Copy link

This diagram outlines the 2.6 infrastructure topology that Red Hat has tested with this deployment model.

Figure 4.12. 2.6 infrastructure topology diagram

2.6 growth topology
View larger image
2.6 growth topology

The following table highlights the requirements for upgrading from Ansible Automation Platform 2.4 to 2.6.

Expand
Existing 2.4 topologyTested 2.6 topologyRequirements for each pod

Non-redundant automation controller and automation hub deployment:

  • One automation controller web pod
  • One automation controller task pod
  • One automation hub web pod
  • One automation hub API pod
  • Two automation hub content pods
  • Two automation hub worker pods
  • One database pod

Growth topology:

  • One automation controller web pod
  • One automation controller task pod
  • One automation hub web pod
  • One automation hub API pod
  • Two automation hub content pods
  • Two automation hub worker pods
  • One automation hub Redis pod
  • One Event-Driven Ansible controller API pod
  • One Event-Driven Ansible controller activation worker pod
  • One Event-Driven Ansible controller default worker pod
  • One Event-Driven Ansible controller event stream pod
  • One Event-Driven Ansible controller scheduler pod
  • One platform gateway pod
  • One database pod
  • One Redis pod

See the Operator growth topology section of the Tested deployment models guide.

You can upgrade your 2.4 multi node automation controller deployment to a 2.6 enterprise topology. This section outlines the infrastructure changes and requirements for upgrading.

4.3.3.1. 2.4 infrastructure topology diagram
Copy link

This diagram outlines the 2.4 infrastructure topology for this deployment model.

Figure 4.13. 2.4 infrastructure topology diagram

2.4 multi controller topology
View larger image
2.4 multi controller topology
4.3.3.2. 2.6 infrastructure topology diagram
Copy link

This diagram outlines the 2.6 infrastructure topology that Red Hat has tested with this deployment model.

Figure 4.14. 2.6 infrastructure topology diagram

2.6 enterprise topology
View larger image
2.6 enterprise topology

The following table highlights the requirements for upgrading from Ansible Automation Platform 2.4 to 2.6.

Expand
Existing 2.4 topologyTested 2.6 topologyRequirements for each pod

Redundant automation controller-only deployment:

  • One automation controller web pod
  • One automation controller task pod
  • Two automation mesh ingress pods
  • Externally managed database service

Enterprise topology:

  • One automation controller web pod
  • One automation controller task pod
  • One automation hub web pod
  • One automation hub API pod
  • Two automation hub content pods
  • Two automation hub worker pods
  • One automation hub Redis pod
  • One Event-Driven Ansible controller API pod
  • Two Event-Driven Ansible controller activation worker pods
  • Two Event-Driven Ansible controller default worker pods
  • Two Event-Driven Ansible controller event stream pods
  • One Event-Driven Ansible controller scheduler pod
  • One platform gateway pod
  • Two automation mesh ingress pods
  • Externally managed database service
  • Externally managed Redis
  • Externally managed object storage service (for automation hub)

See the Operator enterprise topology section of the Tested deployment models guide.

You can upgrade your 2.4 multi node automation controller and automation hub deployment to a 2.6 enterprise topology. This section outlines the infrastructure changes and requirements for upgrading.

4.3.4.1. 2.4 infrastructure topology diagram
Copy link

This diagram outlines the 2.4 infrastructure topology for this deployment model.

Figure 4.15. 2.4 infrastructure topology diagram

2.4 multi controller and hub topology
View larger image
2.4 multi controller and hub topology
4.3.4.2. 2.6 infrastructure topology diagram
Copy link

This diagram outlines the 2.6 infrastructure topology that Red Hat has tested with this deployment model.

Figure 4.16. 2.6 infrastructure topology diagram

2.6 enterprise topology
View larger image
2.6 enterprise topology

The following table highlights the requirements for upgrading from Ansible Automation Platform 2.4 to 2.6.

Expand
Existing 2.4 topologyTested 2.6 topologyRequirements for each pod

Redundant deployment with automation controller and automation hub:

  • One automation controller web pod
  • One automation controller task pod
  • Two automation mesh ingress pods
  • One automation hub web pod
  • One automation hub API pod
  • Two automation hub content pods
  • Two automation hub worker pods
  • Externally managed database service

Enterprise topology:

  • One automation controller web pod
  • One automation controller task pod
  • One automation hub web pod
  • One automation hub API pod
  • Two automation hub content pods
  • Two automation hub worker pods
  • One automation hub Redis pod
  • One Event-Driven Ansible controller API pod
  • Two Event-Driven Ansible controller activation worker pods
  • Two Event-Driven Ansible controller default worker pods
  • Two Event-Driven Ansible controller event stream pods
  • One Event-Driven Ansible controller scheduler pod
  • One platform gateway pod
  • Two automation mesh ingress pods
  • Externally managed database service
  • Externally managed Redis
  • Externally managed object storage service (for automation hub)

See the Operator enterprise topology section of the Tested deployment models guide.

You can upgrade your 2.5 growth topology to a 2.6 growth topology on OpenShift Container Platform. The topologies are the same between Ansible Automation Platform 2.5 and 2.6.

For more information about the growth topology infrastructure requirements and configuration details, see the Operator growth topology section of Tested deployment models.

You can upgrade your 2.5 enterprise topology to a 2.6 enterprise topology on OpenShift Container Platform. The topologies are the same between Ansible Automation Platform 2.5 and 2.6.

For more information about the enterprise topology infrastructure requirements and configuration details, see the Operator enterprise topology section of Tested deployment models.

During the upgrade process to Ansible Automation Platform 2.6, Identity Access Management (IAM) data, including users, teams, organizations, their memberships, and associated roles, is migrated from automation controller and automation hub to platform gateway. This migration establishes automation controller as the primary source of IAM data for platform gateway, ensuring continuity of user memberships and appropriate platform-level role assignments.

Note

We recommend upgrading directly from the latest version of 2.4 to Ansible Automation Platform 2.6, without using 2.5 as an intermediate step, as the upgrade process to 2.6 is less complex.

It is possible for customers to upgrade directly from the latest 2.4 version to 2.6. On startup, 2.6 platform services rename their service-specific roles to platform-wide roles, as shown in the following table.

Expand
2.4 role2.6 equivalent

Automation controller auditor

Platform auditor

Automation controller superuser/administrator (flag)

Platform superuser/administrator (flag)

Automation controller organization admin

Organization administrator

Automation controller organization member

Organization member

Automation controller team admin

Team administrator

Automation hub administrator

Team member (user)

Automation controller team member (user)

Team member (user)

Automation hub team member (user)

Team member (user)

Additionally, note the following behavior when upgrading to 2.6:

  • After upgrading, automation controller entity relationships, such as user associations with organizations, teams, or role sets, remain consistent in platform gateway. This applies to both existing entities moved during the upgrade and any new entities (users, teams, organizations) created in automation controller and subsequently moved in a 2.6 environment.
  • Automation controller user types (normal, superuser and auditor) are mapped to platform gateway user types during the upgrade process.
  • Where team names match between automation hub and platform gateway, for example, "Team A" exists in both, user memberships from automation hub are transferred to the corresponding team in platform gateway. This reduces the need to manually re-create memberships.
  • If users exist only in automation hub, they are not moved to [Gateway]. You must manually re-create these users after upgrading. However, if a user has the same username in both automation controller and automation hub, the automation controller account is part of the regular data movement. Users who are not migrated need to have their passwords reset, but should keep the same permissions.
  • Data movement also moves private automation hub but excludes Event-Driven Ansible data.
  • Event-Driven Ansible users are not moved to platform gateway and must be recreated manually after upgrading.

  • Automation hub users must be recreated if they cannot be moved as part of the upgrade. A user might not be migrated for the following reasons:

    • The user’s account exists only in automation hub and not in automation controller.
    • Duplicate usernames exist in both automation hub and automation controller, but they belong to different people.
    • A discrepancy in the username, email, or other identifying attributes exists between the two services, which prevents the system from correctly merging the accounts.
  • Automation hub admins are converted to normal users if they are able to be merged with automation controller users.
  • The automation controller UI is updated to reflect the automation controller data moved as platform-level entities along with their roles.
  • The automation controller setting Organization Admins Can Manage Users and Teams applies to organization admins in 2.6.

5.1.1. Nested team behavior changes
Copy link

Ansible Automation Platform 2.5 and later versions no longer support nested team structures. This affects the UI, API, and collections.

In version 2.4, users could inherit permissions from multiple teams simultaneously through nested team structures created using REST APIs and collections. For example, a user on Team A could inherit permissions for Team B if Team B was nested under Team A (User → Team A → Team B). The user interface in 2.4 did not expose this capability; it was only possible through the API and collections.

During an upgrade from Ansible Automation Platform 2.4 to 2.6, nested teams are converted to a direct user-to-teams mapping. This means that instead of inheriting permissions through a nested structure, users are directly assigned to each team they have permissions for. For instance, if a user previously had permissions through "User → Team A → Team B," after the upgrade, this becomes "User → Team A" and "User → Team B".

Impact and planning

  • Users can still belong to one or more teams and simultaneously inherit permissions from those teams.
  • Organizations that use integrations or automations with nested teams in their 2.4 deployment must plan to change this structure to a direct user-to-teams mapping.
Important

Before upgrading from Ansible Automation Platform 2.4, change any integrations or automations that implement nested teams to a direct user-to-teams mapping to avoid unexpected behavior in 2.5 and later.

When upgrading from Ansible Automation Platform 2.5 to 2.6, existing authenticators and their mappings in platform gateway continue to function as they are, with no changes being imported. This is because the core authentication service in 2.5 is already platform gateway, so a migration of this data is not needed.

5.2.1. Automation controller
Copy link

Customers upgrading from 2.5 to 2.6 must also begin moving away from using nested teams in automation controller APIs, as future releases will disable direct access to service APIs. After the upgrade, user data is synchronized between automation controller and the platform-wide authentication gateway.

Automation controller users, teams, roles, and organizations should become platform entities upon upgrade without the need to run additional "merge" processes. Customers that first upgraded from 2.4 to 2.5 will have teams that existed in 2.4 merged into platform gateway when they upgrade from 2.5 to 2.6.

Roles should apply the permission model for non-admin access to execution, content, and event services.

5.2.2. Automation hub
Copy link

The following apply:

  • A private automation hub admin (Automation Content Administrator) in 2.5 will be removed in the upgraded version and for this user the permissions must be reassigned manually as part of the data movement process.
Important

If teams with the same name exist in both automation hub and within the platform-wide authentication gateway, users from automation hub will be automatically added to corresponding teams within the platform-wide authentication gateway, and new teams will be created if they do not exist. This approach aims to retain team memberships, but requires careful review of permissions post-upgrade.

  • If you rely on automation hub Single Sign-On (SSO) to access the automation hub user interface (UI), automation hub SSO logins will no longer function after the upgrade. However, API tokens will remain active. Therefore, automated processes or systems that use API tokens for authentication will continue to operate without interruption. If your workflows predominantly rely on API access, the impact might be minimal. However, if users primarily access the UI through SSO, they will need to take action post-upgrade.
  • To restore UI access for users who previously relied on automation hub SSO, you need to reconfigure SSO within Ansible Automation Platform to be able to login. For further information, see Configuring Ansible Automation Platform Central Authentication Generic OIDC Settings and Red Hat SSO/KEYCLOAK for Red Hat SSO and Ansible Automation Platform.
  • Automation controller admins will become platform admins and can administer automation hub.
  • If you upgraded from 2.4 to 2.6 with both automation controller and private automation hub, then a dialog appears in the product post upgrade that informs you that there are steps to take in order to reconfigure private automation hub. This dialog can either display information in-product, or link to a product doc or Knowledge Base article. In either case, you will be guided to take action from within the product and not be expected to find that information unprompted.
  • If you upgraded from 2.4 to 2.6 from an automation controller-only environment, then the addition of private automation hub and Event-Driven Ansible services involves adding the necessary roles to a normal user account to grant access to those services.

5.2.3. Event-Driven Ansible
Copy link

The following apply:

  • An Event-Driven Ansible administrator (Automation Decisions Administrator) in 2.5 will be removed in the upgraded version and for this user the permissions must be reassigned manually as part of the movement process.
  • For Event-Driven Ansible, you must reset your password to log in to Ansible Automation Platform. You can still use your Event-Driven Ansible username but will require new passwords.
  • If an Event-Driven Ansible user with SSO exists, then they will not have to reset password and should have their permissions moved over as part of the SSO migration.

5.3. Post upgrade
Copy link

It is imperative that administrators verify the assigned permissions for all teams in the platform-wide authentication gateway immediately after the upgrade:

  • Ensure the transferred team members have the correct access rights in the Ansible Automation Platform environment based on the filesystem.
  • Make sure all members that have been merged are, in fact, the same member. Incorrect permissions could lead to access issues or security vulnerabilities.
  • When upgrade to Ansible Automation Platform 2.6 is complete, user accounts that exist in both the automation hub and automation controller systems will be unified, and platform gateway IAM will be the source of truth for users after the data movement.
  • Automation hub and Event-Driven Ansible users must either be recreated or the users that moved from automation controller given permission to use those services.

After your upgrade to automation controller 2.6 is complete, verify that you can log in to the upgraded platform with your existing automation controller credentials (username and password).

Note

To do this, you have must have a automation controller account on Ansible Automation Platform 2.4 or 2.5 with administrative privileges.

The following table provides next steps for each type of user after they have upgraded.

Expand
If you are this type of user before upgrading:Then take these actions after the upgrade:

An automation controller administrator (no automation hub account)

Log in with your automation controller username and password; you are now a platform gateway administrator.

An automation controller normal user (no automation hub account)

Log in with your automation controller username and password; you are now a platform gateway normal user.

A automation hub user (no automation controller account)

Request a password reset from your administrator. When you log in with your new password you will be a platform gateway normal user. You will retain your hub-related permissions.

An automation controller and automation hub user (with the same username in both services)

Log in with your automation controller username and password; your previous two accounts will be merged and you are now a platform gateway normal user.

An automation hub user with SSO (no automation controller account)

Log in with your SSO credentials; you are now a platform gateway normal user.

Chapter 6. Authentication movement
Copy link

During an upgrade from Ansible Automation Platform 2.4 to 2.6, only complete authentication provider configurations are migrated to the new platform gateway.

A configuration is considered complete when it meets the following criteria:

  • LDAP: You must specify a server URL.
  • GitHub and Microsoft Azure AD: You must specify both a key and a secret.
  • OIDC: You must define a key, a secret, and an OIDC endpoint.
  • RADIUS and TACACS+: You must specify the host.

Before proceeding with the upgrade, ensure that you complete the following steps:

  • Create a local administrator account and verify that you can log in to the environment using local authentication. You can also use the default administrator account from the inventory file.
  • Enable the local authenticator in the target environment to ensure a fallback login method is available.

  • Perform a full backup of your existing environment.

    Important

    This is a critical step for data recovery in case any issues occur during the migration process.

Post upgrade

  • Update the callback URLs in your Identity Provider (IdP) configurations after the movement. This is necessary for OAuth and SSO providers to function correctly with the new platform gateway architecture. For more information, see Updating callback URLs for OAuth and SSO providers.
  • Reestablish custom certificates for LDAPS if your LDAP authentication uses custom certificates in the system’s trust store. This configuration is not automatically migrated and you must manually reestablish it.

The movement of existing authentication configurations from a Red Hat Ansible Automation Platform 2.4 automation controller to the new 2.6 platform gateway is automated. The following tables show how settings and mappings from the old automation controller schema are transformed to fit the new platform gateway API schema.

6.1. Authentication type: OIDC
Copy link

General settings

Expand
Automation controller 2.4Platform gateway 2.6
SOCIAL_AUTH_OIDC_KEY: "client-id"
SOCIAL_AUTH_OIDC_SECRET: “client-secret"
SOCIAL_AUTH_OIDC_OIDC_ENDPOINT: "https://idp.example.com"
SOCIAL_AUTH_OIDC_VERIFY_SSL: true
Copy to Clipboard Toggle word wrap 
"configuration": {
  "OIDC_ENDPOINT": "https://idp.example.com",
  "KEY": "client-id",
  "SECRET": "client-secret",
  "VERIFY_SSL": true
}
Copy to Clipboard Toggle word wrap

Mappings

Expand
Automation controller 2.4Platform gateway 2.6
AUTH_LDAP_ORGANIZATION_MAP:
 "LDAP Organization":
     users: true
Copy to Clipboard Toggle word wrap 
  "name": "Default - Users (users)",
  "map_type": "organization",
  "order": 1,
  "authenticator": -1,
  "triggers": {
    "users": true
  },
  "organization": "Default",
  "team": null,
  "role": "Organization Member",
  "revoke": true
}
Copy to Clipboard Toggle word wrap 
SOCIAL_AUTH_SAML_USER_FLAGS_BY_ATTR:
 is_superuser_attr: "is_superuser"
 is_superuser_value: "true"
Copy to Clipboard Toggle word wrap 
{
  "name": "is_superuser - role",
  "authenticator": -1,
  "revoke": true,
  "map_type": "is_superuser",
  "team": null,
  "organization": null,
  "triggers": {
    "attributes": {
      "is_superuser": {
        "has_or": [
          "true"
        ]
      }
    }
  },
  "order": 2
}
Copy to Clipboard Toggle word wrap

6.2. Authentication type: LDAP
Copy link

General settings

Expand
Automation controller 2.4Platform gateway 2.6
AUTH_LDAP_SERVER_URI: "ldap://ldap.example.com:389"
AUTH_LDAP_BIND_DN: "cn=admin,dc=example,dc=org"
AUTH_LDAP_BIND_PASSWORD: "password"
AUTH_LDAP_START_TLS: false
AUTH_LDAP_USER_SEARCH: [
  "ou=users,dc=example,dc=org",
  "SCOPE_SUBTREE", "(cn=%(user)s)"
]
AUTH_LDAP_USER_ATTR_MAP: {
  "first_name": "givenName",
  "last_name": "sn",
  "email": "mail"
}
Copy to Clipboard Toggle word wrap 
"configuration": {
  "SERVER_URI": "ldap://ldap.example.com:389",
  "BIND_DN": "cn=admin,dc=example,dc=org",
  "BIND_PASSWORD": "password",
  "START_TLS": false,
  "USER_SEARCH": [
    "ou=users,dc=example,dc=org",
    "SCOPE_SUBTREE",
   "(cn=%(user)s)"
  ],
  "USER_ATTR_MAP": {
    "first_name": "givenName",
    "last_name": "sn",
    "email": "mail"
  }
}
Copy to Clipboard Toggle word wrap

Mappings

Expand
Automation controller 2.4Platform gateway 2.6
AUTH_LDAP_ORGANIZATION_MAP:
 "LDAP Organization":
     users: true
     admins:
     - "cn=awx_org_admins,ou=groups,dc=example,dc=org"
Copy to Clipboard Toggle word wrap 
{
  "name": "LDAP Organization - Admins cn=awx_org_admins,ou=groups,dc=example,dc=org",
  "map_type": "organization",
  "order": 1,
  "authenticator": -1,
  "triggers": {
    "groups": {
      "has_or": [
        "cn=awx_org_admins,ou=groups,dc=example,dc=org"
      ]
    }
  },
  "organization": "LDAP Organization",
  "team": null,
  "role": "Organization Admin",
  "revoke": false
}
Copy to Clipboard Toggle word wrap 
AUTH_LDAP_USER_FLAGS_BY_GROUP:
  is_superuser:
    - 'cn=awx_admins,ou=groups,dc=example,dc=org'
Copy to Clipboard Toggle word wrap 
{
  "name": "is_superuser - role",
  "authenticator": -1,
  "revoke": true,
  "map_type": "is_superuser",
  "team": null,
  "organization": null,
  "triggers": {
    "groups": {
   "has_or": [
        "cn=awx_admins,ou=groups,dc=example,dc=org"
      ]
    }
  },
  "order": 2
}
Copy to Clipboard Toggle word wrap

6.3. Authentication type: SAML
Copy link

General settings

Expand
Automation controller 2.4Platform gateway 2.6
SOCIAL_AUTH_SAML_ENABLED_IDPS:
  Keycloak: null
  entity_id: 'https://idp.example.com/auth/realms/awx'
  url: 'https://idp.example.com/auth/realms/awx/protocol/saml'
  x509cert: MIICert...
  attr_username: username
  attr_email: email
SOCIAL_AUTH_SAML_SP_ENTITY_ID: 'https://controller.example.com:8043'
SOCIAL_AUTH_SAML_SP_PUBLIC_CERT: MIICertPublic...
SOCIAL_AUTH_SAML_SP_PRIVATE_KEY: MIIKeyPrivate...
Copy to Clipboard Toggle word wrap 
"configuration": {
  "IDP_URL": "https://idp.example.com/auth/realms/awx/protocol/saml",
  "IDP_X509_CERT": "-----BEGIN CERTIFICATE-----\nMIICert...\n-----END CERTIFICATE-----",
  "IDP_ENTITY_ID": "https://idp.example.com/auth/realms/awx",
  "IDP_ATTR_EMAIL": "email",
  "IDP_ATTR_USERNAME": "username",
  "SP_ENTITY_ID": "https://controller.example.com:8043",
  "SP_PUBLIC_CERT": "MIICertPublic...",
  "SP_PRIVATE_KEY": "MIIKeyPrivate..."
}
Copy to Clipboard Toggle word wrap

Mappings

Expand
Automation controller 2.4Platform gateway 2.6
SOCIAL_AUTH_SAML_ORGANIZATION_MAP:
 "Default":
    users: true
Copy to Clipboard Toggle word wrap 
{
  "name": "Default - Users (users)",
  "map_type": "organization",
  "order": 1,
  "authenticator": -1,
  "triggers": {
    "users": true
  },
  "organization": "Default",
  "team": null,
  "role": "Organization Member",
  "revoke": true
}
Copy to Clipboard Toggle word wrap 
SOCIAL_AUTH_SAML_USER_FLAGS_BY_ATTR:
 is_superuser_attr: "is_superuser"
 is_superuser_value: "true"
Copy to Clipboard Toggle word wrap 
{
  "name": "is_superuser - role",
  "authenticator": -1,
  "revoke": true,
  "map_type": "is_superuser",
  "team": null,
  "organization": null,
  "triggers": {
    "attributes": {
      "is_superuser": {
        "has_or": [
          "true"
        ]
      }
    }
  },
  "order": 2
}
Copy to Clipboard Toggle word wrap

6.4. Authentication type: Github
Copy link

General settings

Expand
Automation controller 2.4Platform gateway 2.6
SOCIAL_AUTH_GITHUB_KEY: client-id
SOCIAL_AUTH_GITHUB_SECRET: client-secret
SOCIAL_AUTH_GITHUB_SCOPE:
  - 'user:email'
  - 'read:org'
Copy to Clipboard Toggle word wrap 
{
  "configuration": {
    "KEY": "client-id",
    "SECRET": "client-secret",
    "SCOPE": [
      "user:email",
      "read:org"
    ]
  }
}
Copy to Clipboard Toggle word wrap

Mappings

Expand
Automation controller 2.4Platform gateway 2.6
SOCIAL_AUTH_GITHUB_ORGANIZATION_MAP:
 "MyOrg":
     users: true
     admins:
     - "admin-team"
Copy to Clipboard Toggle word wrap 
{
  "name": "MyOrg - Admins admin-team",
  "map_type": "organization",
  "order": 1,
  "authenticator": -1,
  "triggers": {
    "users": {
      "has_or": [
        "admin-team"
      ]
    }
  },
  "organization": "MyOrg",
  "team": null,
  "role": "Organization Admin",
  "revoke": false
}
Copy to Clipboard Toggle word wrap 
SOCIAL_AUTH_GITHUB_TEAM_MAP:
 "Developers":
     organization: "MyOrg"
     users:
     - "dev-team"
Copy to Clipboard Toggle word wrap 
{
  "name": "MyOrg - Developers dev-team",
  "map_type": "team",
  "order": 2,
  "authenticator": -1,
  "triggers": {
    "users": {
      "has_or": [
        "dev-team"
      ]
    }
  },
  "organization": "MyOrg",
  "team": "Developers",
  "role": "Team Member",
  "revoke": false
}
Copy to Clipboard Toggle word wrap

6.5. Authentication type: Azure AD
Copy link

General settings

Expand
Automation controller 2.4Platform gateway 2.6
SOCIAL_AUTH_AZUREAD_OAUTH2_KEY: "application-id"
SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET: "client-secret"
Copy to Clipboard Toggle word wrap 
"configuration": {
  "KEY": "application-id",
  "SECRET": "client-secret",
  "GROUPS_CLAIM": "groups"
}
Copy to Clipboard Toggle word wrap

Mappings

Expand
Automation controller 2.4Platform gateway 2.6
SOCIAL_AUTH_AZUREAD_OAUTH2_ORGANIZATION_MAP:
 "Azure Organization":
     users: true
Copy to Clipboard Toggle word wrap 
{
  "name": "Azure Organization - Users (users)",
  "map_type": "organization",
  "order": 1,
  "authenticator": -1,
  "triggers": {
    "users": true
  },
  "organization": "Azure Organization",
  "team": null,
  "role": "Organization Member",
  "revoke": false
}
Copy to Clipboard Toggle word wrap 
SOCIAL_AUTH_AZUREAD_OAUTH2_TEAM_MAP:
  "Admin Team":
    organization: "Azure Organization"
    users:
    - "admin@company.com"
Copy to Clipboard Toggle word wrap 
{
  "name": "Azure Organization - Admin Team admin@company.com",
  "map_type": "team",
  "order": 2,
  "authenticator": -1,
  "triggers": {
    "emails": {
      "has_or": [
        "admin@company.com"
      ]
    }
  },
  "organization": "Azure Organization",
  "team": "Admin Team",
  "role": "Team Member",
  "revoke": false
}
Copy to Clipboard Toggle word wrap

6.6. Authentication type: RADIUS
Copy link

General settings

Expand
Automation controller 2.4Platform gateway 2.6
RADIUS_SERVER: "radius.example.com"
RADIUS_PORT: 1812
RADIUS_SECRET: "shared-secret"
Copy to Clipboard Toggle word wrap 
"configuration": {
  "SERVER": "radius.example.com",
  "PORT": 1812,
  "SECRET": "shared-secret"
}
Copy to Clipboard Toggle word wrap

Mappings

RADIUS authentication does not support user mappings in either automation controller 2.4 or Platform gateway 2.6.

6.7. Authentication type: TACACS+
Copy link

General settings

Expand
Automation controller 2.4Platform gateway 2.6
TACACSPLUS_HOST: "tacacs.example.com"
TACACSPLUS_PORT: 49
TACACSPLUS_SECRET: "shared-secret"
TACACSPLUS_SESSION_TIMEOUT: 5
TACACSPLUS_AUTH_PROTOCOL: "ascii"
TACACSPLUS_REM_ADDR: false
Copy to Clipboard Toggle word wrap 
"configuration": {
  "HOST": "tacacs.example.com",
  "PORT": 49,
  "SECRET": "shared-secret",
  "SESSION_TIMEOUT": 5,
  "AUTH_PROTOCOL": "ascii",
  "REM_ADDR": false
}
Copy to Clipboard Toggle word wrap

Mappings

TACACS+ authentication does not support user mappings in either automation controller 2.4 or Platform gateway 2.6.

6.8. Authentication type: Google OAuth2
Copy link

General settings

Expand
Automation controller 2.4Platform gateway 2.6
SOCIAL_AUTH_GOOGLE_OAUTH2_KEY: "client-id"
SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET: "client-secret"
SOCIAL_AUTH_GOOGLE_OAUTH2_SCOPE: ["profile", "email"]
Copy to Clipboard Toggle word wrap 
{
  "configuration": {
    "KEY": "client-id",
    "SECRET": "client-secret",
    "REDIRECT_STATE": true,
    "SCOPE": [
      "profile",
      "email"
    ]
  }
}
Copy to Clipboard Toggle word wrap

Mappings

Expand
Automation controller 2.4Platform gateway 2.6
SOCIAL_AUTH_GOOGLE_OAUTH2_ORGANIZATION_MAP:
 "Google Org":
     users: true
Copy to Clipboard Toggle word wrap 
{
  "name": "Google Org - Users (users)",
  "map_type": "organization",
  "order": 1,
  "authenticator": -1,
  "triggers": {
    "users": true
  },
  "organization": "Google Org",
  "team": null,
  "role": "Organization Member",
  "revoke": false
}
Copy to Clipboard Toggle word wrap 
SOCIAL_AUTH_GOOGLE_OAUTH2_TEAM_MAP:
 "Engineers":
     organization: "Google Org"
     users: true
Copy to Clipboard Toggle word wrap 
{
  "name": "Google Org - Engineers (users)",
  "map_type": "team",
  "order": 2,
  "authenticator": -1,
  "triggers": {
    "users": true
  },
  "organization": "Google Org",
  "team": "Engineers",
  "role": "Team Member",
  "revoke": false
}
Copy to Clipboard Toggle word wrap

6.9. The MANAGE_ORGANIZATION_AUTH setting
Copy link

The automation controller setting previously called Organization Admins Can Manage Users and Teams in the UI (or MANAGE_ORGANIZATION_AUTH in the API) controls whether an organization administrator can create users and teams. This setting now exists in both platform gateway and automation controller in Ansible Automation Platform 2.6. During an upgrade the value from automation controller is imported into the platform gateway server. If you decide to change the value of this setting ensure that you change it to the same values in both the platform gateway and automation controller.

Important

For environments with automation running directly against automation controller, maintain a consistent value for MANAGE_ORGANIZATION_AUTH across both automation controller and platform gateway to avoid unexpected behavior.

Ansible Automation Platform 2.5 and 2.6 include changes to API endpoints with the addition of platform gateway. Versions 2.5 and 2.6 expose API access to individual services (automation controller, private automation hub, Event-Driven Ansible) to maintain compatibility with existing REST API integrations. This access will be removed in a future release.

These changes impact your organization if you have 2.4 API calls implemented directly with automation controller or private automation hub, or if you are integrating directly with automation controller or private automation hub hosts. You can use API endpoints exposed through the platform gateway for all Ansible Automation Platform services starting with Ansible Automation Platform 2.5. Moving integrations to API endpoints exposed through the platform gateway that your integrations are not disrupted when direct service API access is removed in a future Ansible Automation Platform release.

This section highlights the changed APIs between 2.4 and 2.5 or 2.6. For detailed API reference information, see the following sources:

  • For platform gateway APIs, see the browsable API at https://<gateway server name>/api/gateway/v1.
  • For automation controller APIs, see the browsable API at https://<gateway server name>/api/controller/v2.
  • For automation hub APIs, see Automation Hub API in API Catalog and Documentation to reference the 2.4 automation hub API.
  • For Event-Driven Ansible, see the browsable API at https://<gateway server name>/api/eda/v1.

7.1. General changes
Copy link

In Ansible Automation Platform 2.5 and later, API endpoints across components changed with the addition of platform gateway.

Expand
Component2.4 and earlier endpoints start with…2.5 and later endpoints start with…Notes

Automation controller

/api/v2/

/api/controller/v2/

 

Automation hub

/api/automation-hub

/api/galaxy/v1

This is the default path, but this path can be changed. For example: https://<local_hub_URL>/api/

Platform gateway

Not applicable

/api/gateway/v1/

 

Event-Driven Ansible

Not applicable

/api/eda/v1/

 

7.2. Specific API changes
Copy link

Specific API mappings for functionality that was centralized through the platform gateway are listed in the following table.

Expand
Component2.4 and earlier endpoints start with…2.5 and 2.6 API endpointsAction needed and notes

Automation controller

/api/v2/o

/api/gateway/v1/tokens/

Token authentication has moved to the platform gateway.

The 2.4 API endpoint is deprecated; it still works in 2.6, but it will not work in a future release.

Automation controller

/api/v2/organizations

/api/gateway/v1/organizations/

Moved to the platform gateway.

The 2.4 API endpoint is deprecated; it still works in 2.6, but it will not work in a future release.

Automation controller

/api/v2/teams

/api/gateway/v1/teams/

Moved to the platform gateway.

The 2.4 API endpoint is deprecated; it still works in 2.6, but it will not work in a future release.

Automation controller

/api/v2/users

/api/gateway/v1/users/

Moved to the platform gateway.

The 2.4 API endpoint is deprecated; it still works in 2.6, but it will not work in a future release.

Automation controller

/api/v2/roles

/api/gateway/v1/role_definitions/

Moved to the platform gateway. This is a list of roles. In Ansible Automation Platform 2.6, this is a list of roles which can apply to all services, and includes custom roles.

The 2.4 API endpoint is only a listing. It still works in 2.6, but it will not work in a future release.

Automation controller

  • /api/v2/roles/{id}/teams/
  • /api/gateway/v1/role_definitions/
  • /api/gateway/v1/role_team_assignments/
  • /api/gateway/v1/role_user_assignments/

A POST request gives a user a role to a resource. This is how to give user permissions.

The 2.4 API endpoint is only a listing. It still works in 2.6, but it will not work in a future release.

Automation controller

The following roles list:

  • /api/v2/teams/{id}/roles/
  • /api/v2/users/{id}/roles/
  • /api/gateway/v1/role_team_assignments/?team={id}
  • /api/gateway/v1/role_user_assignments/?user={id}

List user and team permissions, and give new permissions.

The 2.4 API endpoint is only a listing. It still works in 2.6, but it will not work in a future release.

Automation controller

The following object roles list:

/api/v2/{model_name}/{id}/object_roles/

Example: /api/v2/credentials/42/

/api/gateway/v1/role_user_assignments/?content_type__api_slug={model_api_slug}&object_id={id}

Example: /api/gateway/v1/role_user_assignments/?content_type__api_slug=awx.credential&object_id=42

List the roles that apply to a resource.

Automation controller

The following resource access list:

/api/v2/{model_name}/{id}/access_list/

Example: /api/v2/credentials/42/access_list/

Replacement in 2.6: /api/gateway/v1/role_user_access/{model_api_slug}/{id}/

Example: /api/gateway/v1/role_user_access/awx.credential/42/

List the users who have access to a resource.

Automation hub

/api/v3/login/keycloak

/api/gateway/social/complete/<UID>/

Moved to the platform gateway.

Automation hub

/api/v3/auth/token

/api/gateway/v1/tokens/

Token authentication used for pulling collections will migrate to the platform gateway tokens.

Event-Driven Ansible

N/A

/api/gateway/v1/organizations/

No action needed, as upgrades from 2.4 are not supported.

Event-Driven Ansible

N/A

/api/gateway/v1/teams/

No action needed, as upgrades from 2.4 are not supported.

Event-Driven Ansible

N/A

/api/gateway/v1/users/

No action needed, as upgrades from 2.4 are not supported.

Event-Driven Ansible

N/A

  • /api/gateway/v1/role_definitions/
  • /api/gateway/v1/role_team_assignments/
  • /api/gateway/v1/role_user_assignments/

New role capabilities included as part of the platform gateway API.

Legal Notice
Copy link

Copyright © 2025 Red Hat, Inc.
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.
Back to top
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

© 2025 Red Hat