Ansible Automation Platform 2 Release FAQ

Updated

The purpose of this document is to answer the frequently asked questions in regards to product features or roadmap items as it relates to the Ansible Automation Platform (AAP) 2 Release.

Ansible Automation Platform (migration and general)
Automation Controller
Automation mesh
Private Automation Hub
Ansible Certified Content
Execution Environments
Ansible content navigator
Ansible Core
Red Hat Insights for Ansible Automation Platform
Automation Services Catalog

Ansible Automation Platform (migration and general)

Question: Where are some good resources/links for getting started?
Answer: Here are a few good starting points for AAP 2:

Question: Will an installation for AAP 2 perform an automatic upgrade from an existing AAP 1.2 instance?
Answer: The upgrade process is a deliberate activity that needs planning and scoping, as core capabilities of how automation is run and used may have changed. Migrating from a previous major release include recommendations on how to perform this via a side-by-side method. Please refer to the forthcoming Migration Reference Architecture as well as the Migration Technical Considerations Checklist KBASE as there may be additional manual steps required (such as Content from www.ansible.com is not included.migrating Python virtual environments to execution environments) that depend on the complexity of the existing AAP 1.2 installation.

Question: Can customers perform an in-place upgrade from RHEL 7 to RHEL 8 prior to migrating to AAP 2? Is this supported?
Answer: In-place upgrades from RHEL 7 to RHEL 8 are not supported. A full reinstall of RHEL 8.3 and later is required prior to installing AAP 2. If an upgrade is desired, first deploy a new install of RHEL 8, install your current version of AAP, back up your existing installation on RHEL 7, restore that backup into the new RHEL 8-based deployment, and then upgrade.

Question: Which compute architectures are supported for running Ansible Automation Platform on automation control nodes (that is, automation controller)?
Answer: At this time there are no plans to provide support on any architectures other than x86_64. With the release of execution environments though, execution could theoretically be done on other architectures while the automation controller utilizes x86_64. The Ansible team is evaluating the enabling other architectures for execution environments (not the core platform) in the future.

Question: Does the RHEL included with the Ansible Automation Platform function similarly to traditional RHEL subscriptions where a single subscription can be deployed on either a physical server (up to 2 sockets, stackable) or 2 virtual nodes?
Answer: No. It is a straight count. A quantity of ten (10) RHEL instances are included for the sole purpose of running the Ansible Automation Platform on, and these are single count instances - either on 10 physical servers or 10 virtual servers.

Question: Do I have to purchase Red Hat Enterprise Linux in order to run AAP 2?
Answer: No, every account that purchases AAP 2 includes a quantity of ten (10) RHEL instances for only running the Ansible Automation Platform on.

Question: Will customers with a non-AAP subscription (RHEL or OCP subscription for example) be allowed to download and use the supported execution environments? How about the Ansible Core 2.12 (or newer) RPMs?
Answer: Only AAP subscriptions will be able to access the AAP 2 RPMs in the Customer Portal/CDN. Use of execution environment images from the Red Hat Container Catalog without a corresponding AAP subscription would be unsupported.

Question: Looking at new developer tools such as automation content navigator, execution environment builder, etc., how will Ansible continue to stay simple and approachable to new users?
Answer: There will be essentially no big changes for existing Ansible Automation Platform customers, most of the workflows should function as-is. The new components released in AAP 2 are mostly associated with Developer workflows and give a standardized way to define, build and distribute environments that automation runs in, and that are destined for automation controller. The ansible-navigator run command replaces the ansible-playbook command and provides a way to interact directly with execution environments.

Question: Will AAP 2 run in FIPS enabled mode and in a disconnected environment?
Answer: FIPS for AAP 2 is inherited from RHEL (same as with AAP 1.2) and also in disconnected environments (also same as with AAP 1.2). Customers will need to create a procedure to keep execution environments (distributed from registry.redhat.io) in sync in their disconnected environment.

Question: How can I check the versions of automation controller, Ansible Core, private automation hub and other components included with an associated AAP version?
Answer: Please refer to the This content is not included.errata on the Customer Portal as well as the Ansible Automation Platform Life Cycle Page.

Question: Why was there no big announcement or marketing release associated with Ansible Automation Platform version 2.0 in the summer of 2021?
Answer: A bigger “splash” was made at AnsibleFest 2021 in September that also coincided with Ansible Automation Platform 2.1 including automation mesh as a highly anticipated feature (replacing isolated nodes).

Question: Are there any price changes to the product as part of this release?
Answer: No, not at this time, but this is always subject to change.

Question: What tools does the AAP installer provide to help me upgrade to version 2.1?
Answer: The AAP 2.1 installer attempts to convert AAP 1.2 installer inventory file entries to the new Content from docs.ansible.com is not included.automation mesh configuration. It is, however, recommended to review the AAP 2.1 installer inventory file before performing the upgrade.

You can visually view your automation mesh configuration using a Content from docs.ansible.com is not included.GrahpViz file created by the AAP installer. To create the file, use the generate_dot_file extra variable with the setup command as in the example below:

./setup.sh -- --tag generate_dot_file

This will create a mesh-topology.dot file in the local directory which can be used with the likes of GraphViz and similar utilities to view the proposed configuration.

Automation mesh

Question: What are some of the top-level resources for the automation mesh feature added in AAP 2.1?
Answer:

Question: Do automation mesh features differ based on installation type?
Answer: Yes. You will only get the full automation mesh features in non-OpenShift deployments. OpenShift, being Kubernetes based, uses Content from docs.ansible.com is not included.container groups for automation execution.

Question: What automation mesh features will not be available on OpenShift?
Answer: OpenShift-based AAP 2.1 deployments have a control plane and use Content from docs.ansible.com is not included.container groups to run automation jobs. There is currently no ability to reach in or outside of to connect with external, non-OpenShift deployments.

Question: What ports are required for automation mesh?
Answer:

Automation controller

ALLOW receptor port across all controllers (for mandatory & automatic control plane peering)

Protocol Port Purpose
SSH 22/TCP AAP installation
HTTP/HTTPS 80/443/TCP Web UI, API, Execution Environment (EE) pulls
Receptor 27199/TCP* Automation mesh

_*This is the default TCP port number and can be customized during the AAP installation _

Hop Nodes

ALLOW connections from controller(s) to receptor port

Protocol Port Purpose
SSH 22/TCP AAP installation
Receptor 27199/TCP Automation mesh

Execution Nodes

ALLOW connections from controller(s) to receptor port (for non-hop connected nodes)

ALLOW connections from hop node(s) to receptor port (if relayed through hop nodes)

Protocol Port Purpose
SSH 22/TCP AAP installation
Receptor 27199/TCP Automation mesh for nodes directly peered to controllers
HTTPS 443/TCP EE pulls

Question: Does automation mesh only support TCP?
Answer: Yes. Automation mesh uses and supports TCP as required for TLS signing and validation.

Question: What replaces isolated nodes in AAP 2.1?
Answer: Execution and hop nodes can be jointly or independently used to replace and enhance isolated node functionality.

Question: Does automation mesh have a loop detect function?
Answer: Yes. The AAP 2.1 installer performs configuration sanity checks and alerts you if loops are detected.

Question: Can I incorporate my organization’s Certificate Authority (CA) into automation mesh?
Answer: Yes. Certificates are stored under /etc/receptor/tls. Additional engineering is planned to provide more certificate installation flexibility.

Question: How can I configure automation mesh for restricted networks, such as DMZs?
Answer: You can use Hop nodes in scenarios with restricted network access. For example, a unidirectional TCP connection can be made from an execution node located outside a DMZ to a hop node within the DMZ, based on permitted network controls. Automation mesh uses TCP port 27199 by default. The port number, however, can be customized at installation.

Question: How is load distributed across multiple execution nodes in the same instance group?
Answer: A job gets sent to the worker node with the most capacity available. In the event of multiple worker nodes having the same capacity, the automation job is sent to the first node listed in the Content from docs.ansible.com is not included.Instance Group.

Question: How can I define which automation mesh worker nodes run automation jobs in different environments?
Answer: You can link Content from docs.ansible.com is not included.Instance Groups to multiple automation controller objects, including inventories. Associating an Instance Group to a controller Inventory ensures that automation jobs execute using the automation mesh worker nodes associated with that Instance Group.

Question: Will execution environment (EE) images be copied to the automation mesh worker node each time an automation job runs?
Answer: No. If not already present on the worker node, the EE image is pulled from the configured container registry on first use. Automation mesh worker nodes use Podman to manage EE images locally. You can also set the EE image pull policy in automation controller.

Question: Is automation mesh used to transfer all the data needed to run an automation job?
Answer: Correct. The only exception is that execution nodes need to pull EE images from a container registry, ideally This content is not included.Automation Hub, based on release/tag and the image pull policy defined in controller.

Question: Is it possible to stop execution nodes from accepting new jobs to perform maintenance?
Answer: Yes. You can dissociate execution nodes from an Instance Group in automation controller.

Question: Will the AAP subscription include Red Hat Enterprise Linux (RHEL) entitlements for automation mesh worker nodes?
Answer: An AAP subscription has 10 RHEL entitlements for running AAP components. Please review the following Knowledgebase article for more information on what is included in an Ansible Automation Platform 2 subscription.

Question: How will automation mesh help with multi-site deployments, high availability and disaster recovery?
Answer: Automation mesh introduces fault tolerance and redundancy via native peering capabilities and new features, such as hop nodes. Automation mesh enables localized execution that makes the platform robust to high latency environments and connection disruptions by delivering automation closer to the endpoints that need it. Automation mesh also performs health checks on nodes and, if it's in an unhealthy state, will reroute automation jobs to healthy nodes based on the topology design.

Question: Is there a reference topology or reference architecture that can be referenced?
Answer: Please refer to the Content from www.ansible.com is not included.Deploying Ansible Automation Platform 2.1 reference architecture for more information.

Automation controller

Question: Where did the name "automation controller" come from, and why the change from "Tower"?
Answer: As Ansible Automation Platform 2 continues to evolve, certain functionality has been decoupled (and will continue to be decoupled going forward) from what was formerly known as Ansible Tower. It made sense to introduce the naming change that better reflects these enhancements and the overall position within the Ansible Automation Platform product suite.

Question: Is the automation controller available in container image format?
Answer: Yes, it is available as a container image on the Red Hat Container registry, installable via a fully supported Automation platform operator installed from OperatorHub. This provides a cloud-native, push-button deployment of new Ansible Automation Platform clusters in your OpenShift environment. A fully supported implementation utilizing container groups is also now fully supported (was Technology Preview in AAP 1.2).

Question: Does automation controller support databases other than PostgreSQL 12?
Answer: Not at this time. We are investigating the potential of supporting other commonly deployed enterprise databases, but do not have a timeframe. AAP 2 only supports PostgreSQL 12 as part of the RHEL 8.3 and newer requirements for automation controller. For more details on this, please refer to the Red Hat Automation Platform Database Scope of Coverage page.

Question: Is a highly available (HA) deployment (including database) supported?
Answer: Not at this time. Please feel free to leverage third-party solutions such as Crunchy or EDB to make the PostgreSQL database highly available. Official Red Hat Automation Platform Database Scope of Coverage support is limited to connectivity to the database in this use case.

Question: Is Red Hat OpenShift required for use with automation controller?
Answer: No, it can still be installed and run in physical and virtual environments on standalone RHEL servers just as before in AAP 1.x (Tower 3.x).

Question: Do you support deploying automation controller to native Kubernetes instead of OpenShift?
Answer: The supported container platform for deployments of Red Hat Ansible Automation Platform is Red Hat OpenShift 4.x. Red Hat is currently evaluating the feasibility of adding support for certain Kuberentes implementations for use as execution platforms for automation via execution environments.

Question: I am a customer with isolated nodes in my inventory? Should I upgrade?
Answer: Yes, as of AAP 2.1, there is support for automation mesh (was: isolated nodes) in the AAP 2 release. This new implementation of isolated execution was included in the AAP 2.1 release with the release of the automation mesh.

Question: Will Red Hat consider extending the EOL for Ansible Tower 3.8 in view of the availability of new features?
Answer: There are no such plans at the moment, but if there are real requirements from customers asking for a longer onboarding period, the product team can start taking requests into consideration accordingly. The preferred way for these customers at the moment would be to request a formal support exception.

Private Automation Hub

Question: When will LDAP/SSO be available?
Answer: SSO was recently made available as part of the AAP 2.1 release. LDAP and other identity providers can be added to the RH-SSO configuration. Adding Identity Brokers to RH SSO

Question: When will a highly available/clustered private automation hub be available?
Answer: Private Automation Hub now supports HA for its core services as of the AAP 2.1 release. Customers will still be responsible for making the load balancer, database and storage HA as is expected with the automation controller (and previously Ansible Tower). Check out the following blog entitled "Content from www.ansible.com is not included.Private automation hub - Multi-Hub for resilience."

Question: Can you install Private Automation Hub in an OpenShift environment?
Answer: Yes. When Private Automation Hub is installed via the platform operator, it disables the container image registry support that can be found in the physical/virtual version of Private Automation Hub. This is intentional because container image registry services are provided by the registry supporting OpenShift (Quay, Docker etc..) and automation controller will use that. It is a future roadmap item to enable the private automation hub container registry to provide a more Ansible-focused user experience to introspecting the execution environment images.

Ansible Certified Content

Question: What is it meant by “Ansible content?”
Answer: If AAP and its components are what you need to run and control your automation, Ansible Content is what you do with automation. In its broader definition, Ansible Content includes integration/plumbing, like Modules and Plugins, and reusable business logic built with the Ansible language such as Roles and Playbooks. Ansible Content is packaged into Collections and, in its supported version, delivered through Automation Hub.

Question: What is Ansible Certified Content?
Answer: Ansible Certified Content defines those Collections developed and maintained by either technical partners or Red Hat engineering for which we offer support. Certified partners sign a co-support agreement to provide L2 support where CEE can't solve a customer issue with one of their collections.

Question: What is the SLA for Certified Content and does it require a separate subscription?
Answer: Ansible Certified Content is included in the AAP subscription and follows its contracted SLA. When a ticket is routed to a certified partner, it inherits the SLA customers have with that specific partner.

Question: Why is partner content on Automation Hub not version aligned with Ansible Galaxy?
Answer: Automation Hub and Ansible Galaxy represent the downstream/upstream model for Ansible Content. Partners use Ansible Galaxy to release their latest content and have it tested and eventually contributed by the community; when content is considered stable and supportable it is then published on Automation Hub.

Question: What are Content Domains and do they require a separate subscription?
Answer: Content Domains are our way to split engineering/product management/product marketing/technical marketing efforts to target a specific audience or set of use cases. Examples of Content Domains are Ansible network automation and Ansible security automation. Each Content Domain includes a number of Certified Content Collections, guides and sales/messaging collateral. Content Domains are all included in the AAP subscription.

Question: What are Content Solutions?
Answer: Content Solutions are a subset of one or more Content Domains that provides a more opinionated approach to a partner integration or set of use cases. An example of Content Solution is Ansible for Service Now (certified content collection). While Content Domains leaves customers more freedom to customise their own use cases, Content Solutions want to be a primer, offering a prescriptive approach through both technical collaterals (e.g. Certified Content Collections with dedicated Modules, Plugins or Roles) and guidelines (e.g. Reference Architectures, implementation guides, etc.).

Execution Environments

Question: What content is in the supported execution environment?
Answer: The supported execution environment contains Ansible certified content supported and maintained directly by Red Hat. See Ansible Supported Collections, Versioning, and Release Strategy for details.

Question: Will user-built execution environments be supported when published to a container registry?
Answer: Only supplied EEs on the This content is not included.Red Hat Container Registry are supported by Red Hat support. The use of user-built EEs is supported, and the process of building a custom EE from ansible-builder is supported, but debugging and troubleshooting of the user-built EEs themselves are not supported. This is the same policy as before on playbooks - Red Hat will support the execution and development of them, but Red Hat support does not perform break-fix support on the customer’s playbook itself.

Question: If a user-built execution environment is created (layered) on top of a Red Hat provided execution environment, how is the resulting execution environment supported?
Answer: See above. The issue must be reproducible on a Red Hat supplied execution environment.

Question: RPMs were signed with GPG to validate their integrity. How will this be handled for Ansible Execution Environments container images?
Answer: This should be similar to how other images that are part of the This content is not included.access.redhat.com/containers are validated, the following This content is not included.Blog and KBase article should help.

Ansible content navigator

Question: Is the change to use ansible-navigator something the upstream open source community can access and use too? Is there a similarly packaged solution for the community? If not, why was a different path chosen?
Answer: Yes, Content from github.com is not included.Content from github.com is not included.https://github.com/ansible/ansible-navigator/ , but the community is most likely not going to go this route because a pip install ansible is still for physical/virtual execution on workstations.

Question: Will ansible-navigator be available as a separate download or how can customers deploy on their developer machine?
Answer: Yes, ansible-navigator is available as a separate RPM now available for This content is not included.download in the Customer Portal in the Packages section.

Ansible Core

Question: What is happening after Ansible Engine 2.9?
Answer: Red Hat's strategy has slightly changed from shipping a “kitchen sink” package that is re-packaged from the upstream Ansible Project. Going forward, Ansible Automation Platform will ship the ansible-core package as a standalone RPM as well as be contained within Red Hat delivered execution environments.

Question: Where is Ansible Core 2.11 or newer in RHEL?
Answer: Referring to above, our packaging and delivery strategy has slightly changed. Going forward, layered products will tag the appropriate version of ansible-core into their repos for the use of their content. We hope that this approach will allow for the products to have more control over what they intend to support and ship. We also hope that this alleviates the confusion of AAP entitlements that folks believe are provided with Engine being in RHEL.

Question: Do I receive support for Ansible Engine because it’s provided in RHEL?
Answer: No. Ansible Engine is provided for the purposes of the content of the layered product. Please see above for more information, and a similar situation with Red Hat Satellite (who also packages and distributes Ansible).

Question: Support for Engine 2.9 ended on December 31, 2021. What does this mean for continued use of AAP 1.2?
Answer: Use of Ansible Automation Platform 1.2, which includes Ansible Engine 2.9, will EOL in Nov 2022. Support for standalone Ansible Engine subscriptions without Ansible Automation Platform ended on December 31, 2021. Please refer to the Ansible Automation Platform Life Cycle page.

Question: The migration from Ansible Engine 2.9 to Ansible Core 2.11 is expected to involve potential Playbook changes. Will you be providing any content/tools to support these migrations?
Answer: There are no supported tools at this time that will help with migration of Playbooks, but the resources available on documentation regarding Ansible Content Collections may assist in starting points.

Question: Why did Ansible break backwards compatibility with the ansible-playbook CLI command?
Answer: Instead of saying ansible-playbook you now say ansible-navigator run -- this is a side effect of having execution in containers. We believe ansible-navigator will provide a superior developer user experience for enterprises going forward.

Question: Will I have to use Ansible Navigator now? Why?
Answer: The short answer: Yes. This is the best case scenario from a supportability standpoint. The ansible-runner component is now bundled inside the Red Hat provided EEs and therefore is no direct interface with the ansible-playbook command. Hence ansible-navigator is now the interface to talk to Ansible Core inside the EE. It has the same or very similar subcommands as ansible-playbook with a lot of features on top. Also, hand crafting podman and ansible-runner commands probably isn't an ideal user experience as well -- hence why ansible-navigator was created. That being said, customers may choose not to use ansible-navigator but Red Hat Support will require it if and when support cases are filed.

Red Hat Insights for Ansible Automation Platform

(formerly Ansible Analytics / Automation Analytics)

Question: Where can I get a good intro/primer on Red Hat Insights for Ansible Automation Platform?
Answer: Refer to the following blog entitled "This content is not included.An Introduction to Red Hat Insights for Ansible Automation Platform"

Question: How can I turn this feature on?
Answer: Refer to the following blog entitled "Content from www.ansible.com is not included.How to Activate Red Hat Insights for Ansible Automation Platform

Question : Can I send reports as PDF and/or via Email?
Answer : Yes, this was made available shortly after the AAP 2.1 release.

Question: What are the big features for AAP 2?
Answer: Since Insights for Ansible Automation Platform does NOT launch/deliver its capability in AAP releases, it is developed agile and releases as it can direct to the cloud service.

Automation Services Catalog

Question : I was using Catalog before and now my platforms have disappeared, why?
Answer: Catalog was testing a cloud connection technology (Receptor) that we marked as tech preview, with AAP 2.0 we have completed the trial and are committed to supporting a new cloud connection technology (MQTT). This however did mean any platforms created using the old technical preview connector would disappear from view and requires that products are recreated from the new connector platform. Please checkout the documentation available This content is not included.here.

Question: What Tower version can Services Catalog support.
Answer: Services Catalog is shipping with a new GA version of Cloud Connector. This is available only in AAP 2.0 and requires RHEL 8.4. The AAP installer will install and configure the Cloud Connector and automatically register you back to cloud.redhat.com. We no longer use Sources in cloud.redhat.com for setting up catalog.

Question: When will Catalog be available on-premise?
Answer: We are actively working on a solution for this in the 2022 timeframe.

SBR
Product(s)
Category
Article Type