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

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.

Procedure

1. To find the pod name, run:

   oc get pods | grep operator

2. to view the logs for the pod, run:

   oc logs <operator-pod-name> -f

   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

Procedure

1. Edit the Ansible Automation Platform CR and set the no_log field to false for the component you want to debug.

   For automation controller:

   apiVersion: aap.ansible.com/v1alpha1
   kind: AnsibleAutomationPlatform
   metadata:
     name: myaap
   spec:
     controller:
       no_log: false

   For automation hub:

   apiVersion: aap.ansible.com/v1alpha1
   kind: AnsibleAutomationPlatform
   metadata:
     name: myaap
   spec:
     hub:
       no_log: false

   For Event-Driven Ansible:

   apiVersion: aap.ansible.com/v1alpha1
   kind: AnsibleAutomationPlatform
   metadata:
     name: myaap
   spec:
     eda:
       no_log: false

   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 on the Ansible Automation Platform CR:

   apiVersion: aap.ansible.com/v1alpha1
   kind: AnsibleAutomationPlatform
   metadata:
     name: myaap
     annotations:
       ansible.sdk.operatorframework.io/verbosity: "4"
   spec:
     # ... component configuration ...

Procedure

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

   oc describe -n <namespace> <resource> <resource-name>

2. To view the complete YAML definition of a resource, use the -o yaml flag:

   oc get -n <namespace> <resource> <resource-name> -o yaml

   • For example, to get the YAML for the automationcontroller custom resource, run:

     oc get -n aap automationcontroller aap -o yaml

Procedure

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

   oc explain ansibleautomationplatform.spec

2. To view component-specific configuration options nested under the Ansible Automation Platform CR, query them through the component section:

   oc explain ansibleautomationplatform.spec.controller.postgres_configuration_secret
   oc explain ansibleautomationplatform.spec.controller.route_tls_termination_mechanism
   oc explain ansibleautomationplatform.spec.hub.storage_type
   oc explain ansibleautomationplatform.spec.eda.automation_server_url

3. To explore all nested fields for a specific component, use the --recursive flag:

   oc explain ansibleautomationplatform.spec.controller --recursive
   oc explain ansibleautomationplatform.spec.hub --recursive
   oc explain ansibleautomationplatform.spec.eda --recursive

   Note

   You can also query individual component CRs directly if needed:

   oc explain automationcontroller.spec
   oc explain automationhub.spec
   oc explain eda.spec

   However, when configuring components through the Ansible Automation Platform CR (recommended approach), use the nested paths shown above.

Procedure

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

   oc adm must-gather --image=registry.redhat.io/ansible-automation-platform-26/aap-must-gather-rhel9

   Note

   For version 2.6, the base image name changes to registry.redhat.io/ansible-automation-platform-26/aap-must-gather-rhel9.

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