Este conteúdo não está disponível no idioma selecionado.

Chapter 13. Troubleshooting the Red Hat Ansible Automation Platform Operator on OpenShift Container Platform


This guide provides a collection of commands and tips to help you diagnose and resolve common issues with your Ansible Automation Platform deployment on OpenShift Container Platform. You will learn how to view logs, inspect resources, and collect diagnostic data for support.

13.1. Understanding automation controller operator logs

When the operator deploys an Automation Controller instance, it runs an installer role inside the operator container. If the automation controller’s status is Failed, you must check the automation-controller-operator container logs. These logs provide the installer role’s output and are a critical first step in debugging deployment issues.

13.2. Viewing events in the OpenShift Container Platform

You can view events in the OpenShift Container Platform web console to monitor for errors and troubleshoot issues. This helps you quickly diagnose problems by examining the status of custom resources and their related events.

You can debug by first reviewing the status conditions of the Ansible Automation Platform custom resource (CR) and then checking any nested CRs for errors.

Procedure

  1. Log in to the OpenShift Container Platform web console.
  2. In the navigation menu, select Home Events.
  3. Select your project from the project list.
  4. To view events for a specific resource, navigate to that resource’s page. Many resource pages, such as pods and deployments, have their own Events tab.
  5. Select a resource to bring you to the Pod Details page.

Verification

Check the Conditions section on the Pod details page to confirm no errors are listed in the Message column.

13.3. Viewing operator logs

The following procedure is an example of how to view the logs for an automation-controller-operator pod.

Procedure

  1. To find the pod name, run:

    oc get pods | grep operator
    Copy to Clipboard Toggle word wrap
  2. to view the logs for the pod, run:

    oc logs <operator-pod-name> -f
    Copy to Clipboard Toggle word wrap
    1. Alternatively, to view the logs without first getting the pod name, run:

      oc logs deployments/automation-controller-operator-controller-manager -c automation-controller-manager -f
      Copy to Clipboard Toggle word wrap

13.4. Configuring log verbosity

You can enable task output for debugging on any custom resources (CRs) by setting no_log to false in the spec section of the CR.

The logs then show output for any failed tasks that originally had no_log set to true. The following procedure uses automation controller as an example, but every CR listed in the Core Ansible Automation Platform Resources section supports no_log.

Procedure

  1. Edit the automation controller CR and set the no_log field to false in the spec.

    apiVersion: automationcontroller.ansible.com/v1beta1
    kind: AutomationController
    metadata:
      name: controller-demo
    spec:
      no_log: false
    Copy to Clipboard Toggle word wrap
    Note

    This might expose sensitive data in the logs. On production clusters, this value must generally be set to true unless you are actively debugging an issue.

  2. To increase the Ansible Playbook verbosity from the operator, set the verbosity level using an annotation:

    annotations:
        ansible.sdk.operatorframework.io/verbosity: "4"
    Copy to Clipboard Toggle word wrap

13.5. Inspecting a OpenShift Container Platform resource

To inspect a OpenShift Container Platform resource, you must use the oc command to get a summary or the full YAML definition of the resource.

Procedure

  1. To view a human-readable summary of a resource, run:

    oc describe -n <namespace> <resource> <resource-name>
    Copy to Clipboard Toggle word wrap
  2. To view the complete YAML definition of a resource, use the -o yaml flag:

    oc get -n <namespace> <resource> <resource-name> -o yaml
    Copy to Clipboard Toggle word wrap
    • For example, to get the YAML for the automationcontroller custom resource, run:

      oc get -n aap automationcontroller aap -o yaml
      Copy to Clipboard Toggle word wrap

13.6. Core Ansible Automation Platform resources

The following table lists and describes the core custom resources (CRs) that the Ansible Automation Platform Operator manages. Understanding these resources will help you with advanced troubleshooting and configuration.

Expand
Resource nameDescription

ansibleautomationplatform

CR for deploying the entire Ansible Automation Platform.

ansibleautomationplatformbackup

CR for creating backups of the entire Ansible Automation Platform instance.

ansibleautomationplatformrestore

CR for restoring the entire Ansible Automation Platform instance from a backup.

automationcontroller

CR defining the desired state of an automation controller instance.

automationcontrollerbackup

CR for creating backups of automation controller data and configuration.

automationcontrollerrestore

CR for restoring the automation controller from a backup.

automationhub

CR for deploying an automation hub (Galaxy) instance.

automationhubbackup

CR for creating backups of automation hub data and configuration.

automationhubrestore

CR for restoring automation hub from a backup.

eda

CR for deploying an Event-Driven Ansible (EDA) instance.

edabackup

CR for creating backups of EDA data and configuration.

edarestore

CR for restoring EDA from a backup.

ansiblelightspeed

CR for deploying an Red Hat Ansible Lightspeed instance.

13.7. Standard Kubernetes resources

Standard Kubernetes resources are a core part of the OpenShift Container Platform. The following table describes the standard resources you can inspect to troubleshoot the state and configuration of an application.

Expand
Resource nameDescription

pod

Smallest deployable unit containing one or more containers running the application workloads.

deployment

Manages pod configuration and scaling.

pvc

A PersistentVolumeClaim (PVC) is a request for storage resources, used for persistent data storage.

service

Exposes pods as network services with stable IP addresses and DNS names within the cluster.

ingress

Manages external HTTP and HTTPS access to services within the cluster.

route

An OpenShift-specific resource for exposing services externally (similar to an ingress).

secrets

Stores sensitive data like passwords, tokens, and certificates.

serviceaccount

Provides identity for processes running in pods to access permissions to other Kubernetes resources.

13.8. Discovering custom resource definition configuration parameters

The Ansible Automation Platform Operator manages multiple custom resources (CRs), each with its own configuration parameters. Use the oc explain command to discover all available configuration options for the AnsibleAutomationPlatform CR and its nested components.

Procedure

  1. To see all available configuration parameters for a top-level CR, run:

    oc explain ansibleautomationplatform.spec
    Copy to Clipboard Toggle word wrap
  2. To view specific nested sections, query them directly:

    oc explain automationcontroller.spec.postgres_configuration_secret
    oc explain automationcontroller.spec.route_tls_termination_mechanism
    Copy to Clipboard Toggle word wrap
  3. To explore all nested fields at once, use the --recursive flag:

    oc explain automationcontroller.spec --recursive
    Copy to Clipboard Toggle word wrap

13.9. Collecting Diagnostic Data

Use the oc adm must-gather command to collect comprehensive diagnostic data about your cluster and the Ansible Automation Platform components. This data is essential when contacting Red Hat Support.

Procedure

  1. To start the must-gather tool, run:

    oc adm must-gather --image=registry.redhat.io/ansible-automation-platform-25/aap-must-gather-rhel8
    Copy to Clipboard Toggle word wrap
  2. View the collected data, use the omc tool to query the must-gather tarball as if it were a live cluster.

    omc use <path-to-must-gather>
    omc get pods
    Copy to Clipboard Toggle word wrap

13.10. Debugging crashing pods

If a pod is failing or crashing, use the oc debug command. This command creates a new pod with the same configuration and mounts as the pod you specified, allowing you to access it for debugging.

Procedure

  • To connect to the pod, run:

    oc debug <pod-name>
    Copy to Clipboard Toggle word wrap

13.11. Operator service account error

Manually modifying the aap_operator_service_account user in the Ansible Automation Platform database or UI removes the required is_superuser flag. This action causes a critical failure in the platform gateway operator’s reconciliation loop.

You see the following error:

TASK [ansibleautomationplatform : Create operator service account user] … CommandError: Error: That username is already taken
Copy to Clipboard Toggle word wrap

The Ansible Automation Platform operator automatically recreates the service account when the account is missing. To restore the required superuser privileges, you must remove the existing, incorrectly configured user.

After you delete the user, the platform gateway operator automatically runs its idempotency logic, recreates the account, and ensures it has the necessary is_superuser=True flag, restoring the reconciliation loop’s functionality.

Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat