# AWX Operator on OperatorHub & Troubleshooting Tips

## Presenters
* Christian Adams
* John Westcott

## Overview
* Unveiling that we are adding the AWX Operator to OperatorHub
* How to install from OperatorHub with a single click
* Common mistakes when using the AWX Operator
* AWX Operator troubleshooting tips

## Presenter Notes

* [PRESENTATION LINK](https://docs.google.com/presentation/d/11jZKrFVAydzzyslYLtsnvJ_L3R3_-G7-vM1AOTlonws/edit#slide=id.gfef3c6fb9b_0_81)

## KUSTOMIZE DEMO

## OPERATORHUB DEMO

### AWX Operator on OperatorHub

* link to OperatorHub listing
*

## Common Pitfalls when using the AWX Operator

### Troubleshooting Tips

#### Secrets on the AWX Spec #ToDo

There are many fields on the AWX CR's spec that expect the *name* of a k8s secret, not the secret value itself.

For example,
* secret_key_secret
* tls...

#### Delete old PVC's to avoid conflicts

Say you deployed AWX to test it out and called your deployment "my-awx".
As part of the deployment, a Persistent Volume Claim (PVC) will be created by the name "postgres-13-my-awx-postgres-13-0".

Once you are done testing out the AWX deployment, say you decide you want to create a new one for prod with different settings. The db PVC stays behind in case you want to try to recover any data from it for whatever reason.
If your new AWX custom resource (CR) has the same name, my-awx, it will attempt to use the existing database, however this can cause problems for two reasons:
* If you are now using a different version of AWX, migrations may not line up, particularly if this you have switched to an older version.
* If you have deleted your `my-awx-secret-key` secret, the operator will create a new one for your new deployment, but it won't match the secret key that was used by the original deployment when encrypting/decrypting values from the database. Your AWX deployment will fail as a result.
* This can also occur if you switch to using a custom, supplied secret_key_secret

To avoid this you can do one of the following:
* Delete existing PVC's if you no longer need them
* Name your new deployment something different, like "my-awx-2"

> Note that many users hit this when running an awxrestore because their old deployment still exists and they name the newly restored deployment the same.

#### Quoting extra_settings

Some extra settings passed via the AWX spec file need to be double-quoted

Reference - https://github.com/ansible/awx/issues/11222#issuecomment-939782609

### Common Pitfalls to avoid

1. Please backup your AWX instance before upgrades by creating an AWXBackup object.
* See these docs - https://github.com/ansible/awx-operator/blob/devel/roles/backup/README.md
2. Do not delete your secret_key_secret k8s secret from your namespace!
* This k8s secret is generated by the operator if one is not provided, and is needed for encrypting and decrypting values from the database.
* And AWXBackup will back up the secret to a PVC if the secret is available when the backup is created.
3. When setting resource requests and limits, use Gi and Mi, not Gb and Mb.

### CrashLoopBackoff

This issue occasionally rears its head in some installations. It can happen for a variety of reasons but it indicates that the containers created for AWX by the operator are crashing. This is sometimes related to resource contraints on the ocp cluster itself. Other times there may be container level issues causing the problems. Consult the AWX logs and cluster logs to look for indicators as to what is causing the containers to crash.