Docs: moved user guide segment from readme

docs/user-guide/admin-user-account-configuration.md

@@ -0,0 +1,64 @@
+### Admin user account configuration
+
+There are three variables that are customizable for the admin user account creation.
+
+| Name                  | Description                                  | Default          |
+| --------------------- | -------------------------------------------- | ---------------- |
+| admin_user            | Name of the admin user                       | admin            |
+| admin_email           | Email of the admin user                      | test@example.com |
+| admin_password_secret | Secret that contains the admin user password | Empty string     |
+
+
+> :warning: **admin_password_secret must be a Kubernetes secret and not your text clear password**.
+
+If `admin_password_secret` is not provided, the operator will look for a secret named `<resourcename>-admin-password` for the admin password. If it is not present, the operator will generate a password and create a Secret from it named `<resourcename>-admin-password`.
+
+To retrieve the admin password, run `kubectl get secret <resourcename>-admin-password -o jsonpath="{.data.password}" | base64 --decode ; echo`
+
+The secret that is expected to be passed should be formatted as follow:
+
+```yaml
+---
+apiVersion: v1
+kind: Secret
+metadata:
+  name: <resourcename>-admin-password
+  namespace: <target namespace>
+stringData:
+  password: mysuperlongpassword
+```
+
+### Secret Key Configuration
+
+This key is used to encrypt sensitive data in the database.
+
+| Name              | Description                                           | Default          |
+| ----------------- | ----------------------------------------------------- | ---------------- |
+| secret_key_secret | Secret that contains the symmetric key for encryption | Generated     |
+
+
+> :warning: **secret_key_secret must be a Kubernetes secret and not your text clear secret value**.
+
+If `secret_key_secret` is not provided, the operator will look for a secret named `<resourcename>-secret-key` for the secret key. If it is not present, the operator will generate a password and create a Secret from it named `<resourcename>-secret-key`. It is important to not delete this secret as it will be needed for upgrades and if the pods get scaled down at any point. If you are using a GitOps flow, you will want to pass a secret key secret.
+
+The secret should be formatted as follow:
+
+```yaml
+---
+apiVersion: v1
+kind: Secret
+metadata:
+  name: custom-awx-secret-key
+  namespace: <target namespace>
+stringData:
+  secret_key: supersecuresecretkey
+```
+
+Then specify the secret name on the AWX spec:
+
+```yaml
+---
+spec:
+  ...
+  secret_key_secret: custom-awx-secret-key
+```

docs/user-guide/advanced-configuration/assigning-awx-pods-to-specific-nodes.md

@@ -0,0 +1,90 @@
+#### Assigning AWX pods to specific nodes
+
+You can constrain the AWX pods created by the operator to run on a certain subset of nodes. `node_selector` and `postgres_selector` constrains
+the AWX pods to run only on the nodes that match all the specified key/value pairs. `tolerations` and `postgres_tolerations` allow the AWX
+pods to be scheduled onto nodes with matching taints.
+The ability to specify topologySpreadConstraints is also allowed through `topology_spread_constraints`
+If you want to use affinity rules for your AWX pod you can use the `affinity` option.
+
+If you want to constrain the web and task pods individually, you can do so by specificying the deployment type before the specific setting. For
+example, specifying `task_tolerations` will allow the AWX task pod to be scheduled onto nodes with matching taints. 
+
+| Name                             | Description                              | Default  |
+| -------------------------------- | ---------------------------------------- | -------  |
+| postgres_image                   | Path of the image to pull                | postgres |
+| postgres_image_version           | Image version to pull                    | 13       |
+| node_selector                    | AWX pods' nodeSelector                   | ''       |
+| web_node_selector                | AWX web pods' nodeSelector               | ''       |
+| task_node_selector               | AWX task pods' nodeSelector              | ''       |
+| topology_spread_constraints      | AWX pods' topologySpreadConstraints      | ''       |
+| web_topology_spread_constraints  | AWX web pods' topologySpreadConstraints  | ''       |
+| task_topology_spread_constraints | AWX task pods' topologySpreadConstraints | ''       |
+| affinity                         | AWX pods' affinity rules                 | ''       |
+| web_affinity                     | AWX web pods' affinity rules             | ''       |
+| task_affinity                    | AWX task pods' affinity rules            | ''       |
+| tolerations                      | AWX pods' tolerations                    | ''       |
+| web_tolerations                  | AWX web pods' tolerations                | ''       |
+| task_tolerations                 | AWX task pods' tolerations               | ''       |
+| annotations                      | AWX pods' annotations                    | ''       |
+| postgres_selector                | Postgres pods' nodeSelector              | ''       |
+| postgres_tolerations             | Postgres pods' tolerations               | ''       |
+
+Example of customization could be:
+
+```yaml
+---
+spec:
+  ...
+  node_selector: |
+    disktype: ssd
+    kubernetes.io/arch: amd64
+    kubernetes.io/os: linux
+  topology_spread_constraints: |
+    - maxSkew: 100
+      topologyKey: "topology.kubernetes.io/zone"
+      whenUnsatisfiable: "ScheduleAnyway"
+      labelSelector:
+        matchLabels:
+          app.kubernetes.io/name: "<resourcename>"
+  tolerations: |
+    - key: "dedicated"
+      operator: "Equal"
+      value: "AWX"
+      effect: "NoSchedule"
+  task_tolerations: |
+    - key: "dedicated"
+      operator: "Equal"
+      value: "AWX_task"
+      effect: "NoSchedule"
+  postgres_selector: |
+    disktype: ssd
+    kubernetes.io/arch: amd64
+    kubernetes.io/os: linux
+  postgres_tolerations: |
+    - key: "dedicated"
+      operator: "Equal"
+      value: "AWX"
+      effect: "NoSchedule"
+  affinity:
+    nodeAffinity:
+      preferredDuringSchedulingIgnoredDuringExecution:
+      - weight: 1
+        preference:
+          matchExpressions:
+          - key: another-node-label-key
+            operator: In
+            values:
+            - another-node-label-value
+            - another-node-label-value
+    podAntiAffinity:
+      preferredDuringSchedulingIgnoredDuringExecution:
+      - weight: 100
+        podAffinityTerm:
+          labelSelector:
+            matchExpressions:
+            - key: security
+              operator: In
+              values:
+              - S2
+          topologyKey: topology.kubernetes.io/zone
+```

docs/user-guide/advanced-configuration/auto-upgrade.md

@@ -0,0 +1,35 @@
+#### Auto upgrade
+With this parameter you can influence the behavior during an operator upgrade.  
+If set to `true`, the operator will upgrade the specific instance directly.  
+When the value is set to `false`, and we have a running deployment, the operator will not update the AWX instance.  
+This can be useful when you have multiple AWX instances which you want to upgrade step by step instead of all at once.  
+
+
+| Name         | Description                        | Default |
+| -------------| ---------------------------------- | ------- |
+| auto_upgrade | Automatic upgrade of AWX instances | true    |
+
+Example configuration of `auto_upgrade` parameter
+
+```yaml
+  spec:
+    auto_upgrade: true
+```
+
+##### Upgrade of instances without auto upgrade
+
+There are two ways to upgrade instances which are marked with the 'auto_upgrade: false' flag.  
+
+Changing flags:
+
+- change the auto_upgrade flag on your AWX object to true  
+- wait until the upgrade process of that instance is finished
+- change the auto_upgrade flag on your AWX object back to false  
+
+Delete the deployment:
+
+- delete the deployment object of your AWX instance  
+```
+$ kubectl -n awx delete deployment <yourInstanceName> 
+```
+- wait until the instance gets redeployed  

docs/user-guide/advanced-configuration/containers-resource-requirements.md

@@ -0,0 +1,64 @@
+#### Containers HostAliases Requirements
+
+Sometimes you might need to use [HostAliases](https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/) in web/task containers.
+
+| Name         | Description           | Default |
+| ------------ | --------------------- | ------- |
+| host_aliases | A list of HostAliases | None    |
+
+Example of customization could be:
+
+```yaml
+---
+spec:
+  ...
+  host_aliases:
+    - ip: <name-of-your-ip>
+      hostnames:
+        - <name-of-your-domain>
+```
+
+#### Containers Resource Requirements
+
+The resource requirements for both, the task and the web containers are configurable - both the lower end (requests) and the upper end (limits).
+
+| Name                       | Description                                      | Default                              |
+| -------------------------- | ------------------------------------------------ | ------------------------------------ |
+| web_resource_requirements  | Web container resource requirements              | requests: {cpu: 100m, memory: 128Mi} |
+| task_resource_requirements | Task container resource requirements             | requests: {cpu: 100m, memory: 128Mi} |
+| ee_resource_requirements   | EE control plane container resource requirements | requests: {cpu: 100m, memory: 128Mi} |
+
+Example of customization could be:
+
+```yaml
+---
+spec:
+  ...
+  web_resource_requirements:
+    requests:
+      cpu: 250m
+      memory: 2Gi
+      ephemeral-storage: 100M
+    limits:
+      cpu: 1000m
+      memory: 4Gi
+      ephemeral-storage: 500M
+  task_resource_requirements:
+    requests:
+      cpu: 250m
+      memory: 1Gi
+      ephemeral-storage: 100M
+    limits:
+      cpu: 2000m
+      memory: 2Gi
+      ephemeral-storage: 500M
+  ee_resource_requirements:
+    requests:
+      cpu: 250m
+      memory: 100Mi
+      ephemeral-storage: 100M
+    limits:
+      cpu: 500m
+      memory: 2Gi
+      ephemeral-storage: 500M
+```

docs/user-guide/advanced-configuration/csrf-cookie-secure-setting.md

@@ -0,0 +1,14 @@
+#### CSRF Cookie Secure Setting
+
+With `csrf_cookie_secure`, you can pass the value for `CSRF_COOKIE_SECURE` to `/etc/tower/settings.py`
+
+| Name               | Description        | Default |
+| ------------------ | ------------------ | ------- |
+| csrf_cookie_secure | CSRF Cookie Secure | ''      |
+
+Example configuration of the `csrf_cookie_secure` setting:
+
+```yaml
+  spec:
+    csrf_cookie_secure: 'False'
+```