šŸ’” Solution: Scenario 1 ā€” Automation Hub storage issue

This page provides the detailed solution for Scenario 1. Review these steps after you have attempted the diagnosis and resolution yourself.

šŸ›‘ Problem: Missing ReadWriteMany (RWX) storage class

Diagnosis

The Automation Hub pods were failing due to an inability to provision or mount the required Persistent Volume Claim (PVC). In a typical HA deployment, multiple Hub pods need to access the same storage simultaneously, which requires a storage type that supports the ReadWriteMany (RWX) access mode.

The original StorageClass was set to a type that only supports ReadWriteOnce (RWO), causing PVC binding and pod scheduling failures.

šŸ› ļø Resolution: Updating the storage class

The fix involves modifying the main Ansible Automation Platform Custom Resource (CR) to specify a valid RWX-capable StorageClass, followed by manually forcing a clean reconciliation.

1. Modify the AAP custom resource

If you don’t specify a storage class, the operator will use the cluster default storage class. In this case the default storage class is RWO storage; Automation Hub requires RWX storage.

In the OpenShift Console:

  1. Navigate to Ecosystem ā†’ Installed Operators and select your namespace from the dropdown.

  2. Click on Ansible Automation Platform in the operator list.

  3. Click the AnsibleAutomationPlatform tab to see your CR instances.

  4. Click on your AAP instance (named user-guid-aap).

  5. Switch to the YAML tab and update the file_storage_storage_class field in the Hub section:

# Example snippet of the modified AAP CR
spec:
  hub:
    file_storage_storage_class: ocs-external-storagecluster-cephfs

2. Delete the old PVC

The existing PVC created with the incorrect StorageClass must be deleted so the Operator can provision a new one with the correct StorageClass.

In the OpenShift Console, navigate to Storage ā†’ PersistentVolumeClaims and select your namespace from the dropdown. Find the Hub file storage PVC, click the three-dot menu on the right, and select Delete PersistentVolumeClaim.

3. Delete the hub-api deployment

The current hub-api deployment is holding on to old information and needs to be deleted so the Operator can redeploy it cleanly.

In the OpenShift Console, navigate to Workloads ā†’ Deployments and select your namespace. Find the hub-api deployment, click the three-dot menu on the right, and select Delete Deployment.

4. Force reconciliation

Manually delete the Hub Operator manager pod to trigger the Operator to recognize the change and provision the new PVC correctly.

In the OpenShift Console, navigate to Workloads ā†’ Pods and select your namespace. Find the Hub Operator manager pod (named automation-hub-operator-controller-manager-…​), click the three-dot menu on the right, and select Delete Pod.

5. Verification

Monitor Workloads ā†’ Pods. The Operator will provision a new PVC, redeploy the hub-api Deployment, and the Hub pods will successfully mount the volume and transition to a Running and Ready state.