Merge branch 'devel' into dependabot/pip/docs/docsite/sphinx-ansible-theme-0.10.3

docs/build_awx_image.md

@@ -2,12 +2,10 @@
 
 ## Build & Push Image
 
-To build a custom awx image to use with the awx-operator, use the `build_image` role:
+To build a custom awx image to use with the awx-operator:
 
 ```
-$ ansible-playbook tools/ansible/build.yml \
-    -e awx_image=registry.example.com/ansible/awx \
-    -e awx_image_tag=test -v
+make awx-kube-build
 ```
 
 > Note: The development image (`make docker-compose-build`) will not work with the awx-operator, the UI is not built in that image, among other things (see Dockerfile.j2 for more info).

docs/bulk_api.md

@@ -3,6 +3,7 @@
 Bulk API endpoints allows to perform bulk operations in single web request. There are currently following bulk api actions:
 - /api/v2/bulk/job_launch
 - /api/v2/bulk/host_create
+- /api/v2/bulk/host_delete
 
 Making individual API calls in rapid succession or at high concurrency can overwhelm AWX's ability to serve web requests. When the application's ability to serve is exhausted, clients often receive 504 timeout errors.
 
@@ -99,3 +100,20 @@ Following is an example of a post request at the /api/v2/bulk/host_create:
 The above will add 6 hosts in the inventory.
 
 The maximum number of hosts allowed to be added is controlled by the setting `BULK_HOST_MAX_CREATE`. The default is 100 hosts. Additionally, nginx limits the maximum payload size, which is very likely when posting a large number of hosts in one request with variable data associated with them. The maximum payload size is 1MB unless overridden in your nginx config.
+
+
+## Bulk Host Delete
+
+Provides feature in the API that allows a single web request to delete multiple hosts from an inventory.
+
+Following is an example of a post request at the /api/v2/bulk/host_delete:
+
+
+    {
+        "hosts": [3, 4, 5, 6, 7 ,8, 9, 10]
+    }
+
+
+The above will delete 8 hosts from the inventory.
+
+The maximum number of hosts allowed to be deleted is controlled by the setting `BULK_HOST_MAX_DELETE`. The default is 250 hosts. Additionally, nginx limits the maximum payload size, which is very likely when posting a large number of hosts in one request with variable data associated with them. The maximum payload size is 1MB unless overridden in your nginx config.

docs/docsite/conf.py

@@ -16,11 +16,11 @@ pubdate = datetime.strptime(pubdateshort, '%Y-%m-%d').strftime('%B %d, %Y')
 
 # The name for this set of Sphinx documents.  If None, it defaults to
 # "<project> v<release> documentation".
-#html_title = None
+# html_title = None
 html_title = 'Ansible AWX community documentation'
 
 # A shorter title for the navigation bar.  Default is the same as html_title.
-#html_short_title = None
+# html_short_title = None
 html_short_title = 'AWX community documentation'
 
 htmlhelp_basename = 'AWX_docs'
@@ -54,8 +54,8 @@ release = 'AWX latest'
 
 language = 'en'
 
-locale_dirs = ['locale/']   # path is example but recommended.
-gettext_compact = False     # optional.
+locale_dirs = ['locale/']  # path is example but recommended.
+gettext_compact = False  # optional.
 
 rst_epilog = """
 .. |atqi| replace:: *AWX Quick Installation Guide*
@@ -88,4 +88,8 @@ rst_epilog = """
 .. |rhaap| replace:: Red Hat Ansible Automation Platform
 .. |RHAT| replace:: Red Hat Ansible Automation Platform controller
 
-""" % (version, pubdateshort, pubdate)
+""" % (
+    version,
+    pubdateshort,
+    pubdate,
+)

docs/docsite/requirements.txt

@@ -23,7 +23,7 @@ idna==3.4
     # via requests
 imagesize==1.4.1
     # via sphinx
-jinja2==3.1.2
+jinja2==3.1.3
     # via
     #   -r requirements.in
     #   sphinx

docs/docsite/rst/administration/awx-manage.rst

@@ -6,7 +6,7 @@ The *awx-manage* Utility
 .. index:: 
    single: awx-manage
 
-The ``awx-manage`` utility is used to access detailed internal information of AWX. Commands for ``awx-manage`` should run as the ``awx`` or ``root`` user.
+The ``awx-manage`` utility is used to access detailed internal information of AWX. Commands for ``awx-manage`` should run as the ``awx`` user only.
 
 .. warning:: 
          Running awx-manage commands via playbook is not recommended or supported.

docs/docsite/rst/administration/ent_auth.rst

@@ -557,7 +557,7 @@ Terminal Access Controller Access-Control System Plus (TACACS+) is a protocol th
 
 Generic OIDC settings
 ----------------------
-Similar to SAML, OpenID Connect (OIDC) is uses the OAuth 2.0 framework. It allows third-party applications to verify the identity and obtain basic end-user information. The main difference between OIDC and SMAL is that SAML has a service provider (SP)-to-IdP trust relationship, whereas OIDC establishes the trust with the channel (HTTPS) that is used to obtain the security token. To obtain the credentials needed to setup OIDC with AWX, refer to the documentation from the identity provider (IdP) of your choice that has OIDC support.
+Similar to SAML, OpenID Connect (OIDC) is uses the OAuth 2.0 framework. It allows third-party applications to verify the identity and obtain basic end-user information. The main difference between OIDC and SAML is that SAML has a service provider (SP)-to-IdP trust relationship, whereas OIDC establishes the trust with the channel (HTTPS) that is used to obtain the security token. To obtain the credentials needed to setup OIDC with AWX, refer to the documentation from the identity provider (IdP) of your choice that has OIDC support.
 
 To configure OIDC in AWX:
 

docs/docsite/rst/administration/instances.rst

@@ -1,7 +1,7 @@
 .. _ag_instances:
 
 Managing Capacity With Instances
-----------------------------------
+=================================
 
 .. index::
    pair: topology;capacity
@@ -9,12 +9,32 @@ Managing Capacity With Instances
    pair: remove;capacity
    pair: add;capacity
 
-Scaling your mesh is only available on Openshift deployments of AWX and is possible through adding or removing nodes from your cluster dynamically, through the **Instances** resource of the AWX User Interface, without running the installation script.
+Scaling your mesh is only available on Openshift and Kubernetes (K8S) deployments of AWX and is possible through adding or removing nodes from your cluster dynamically, through the **Instances** resource of the AWX User Interface, without running the installation script.
+
+Instances serve as nodes in your mesh topology. Automation mesh allows you to extend the footprint of your automation. Where you launch a job and where the ``ansible-playbook`` runs can be in different locations.
+
+.. image:: ../common/images/instances_mesh_concept.drawio.png
+	:alt: Site A pointing to Site B and dotted arrows to two hosts from Site B 
+
+Automation mesh is useful for:
+
+- traversing difficult network topologies
+- bringing execution capabilities (the machine running ``ansible-playbook``) closer to your target hosts
+
+The nodes (control, hop, and execution instances) are interconnected via receptor, forming a virtual mesh.
+
+.. image:: ../common/images/instances_mesh_concept_with_nodes.drawio.png
+	:alt: Control node pointing to hop node, which is pointing to two execution nodes.  
+
 
 Prerequisites
-~~~~~~~~~~~~~~
+--------------
 
-- The system that is going to run the ``ansible-playbook`` requires the collection ``ansible.receptor`` to be installed:
+- |rhel| (RHEL) or Debian operating system. Bring a machine online with a compatible Red Hat family OS (e.g. RHEL 8 and 9) or Debian 11. This machine requires a static IP, or a resolvable DNS hostname that the AWX cluster can access. If the ``listener_port`` is defined, the machine will also need an available open port on which to establish inbound TCP connections (e.g. 27199).
+
+  In general, the more CPU cores and memory the machine has, the more jobs that can be scheduled to run on that machine at once. See :ref:`ug_job_concurrency` for more information on capacity.
+
+- The system that is going to run the install bundle to setup the remote node requires the collection ``ansible.receptor`` to be installed:
 
 	- If machine has access to the internet:
 
@@ -25,39 +45,233 @@ Prerequisites
 
 	Installing the receptor collection dependency from the ``requirements.yml`` file will consistently retrieve the receptor version specified there, as well as any other collection dependencies that may be needed in the future.
 
-	- If machine does not have access to the internet, refer to `Downloading a collection from Automation Hub <https://docs.ansible.com/ansible/latest/galaxy/user_guide.html#downloading-a-collection-from-automation-hub>`_ to configure `Automation Hub <https://console.redhat.com/ansible/automation-hub>`_ in Ansible Galaxy locally.
-
-
-- If you are using the default |ee| (provided with AWX) to run on remote execution nodes, you must add a pull secret in AWX that contains the credential for pulling the |ee| image. To do this, create a pull secret on the AWX namespace and configure the ``ee_pull_credentials_secret`` parameter in the Operator:
-
-	1. Create a secret:
-	::
-
-		oc create secret generic ee-pull-secret \
-    	  	 --from-literal=username=<username> \
-    	  	 --from-literal=password=<password> \
-    	  	 --from-literal=url=registry.redhat.io
-
-	::
-
-		oc edit awx <instance name>
-
-	2. Add ``ee_pull_credentials_secret ee-pull-secret`` to the spec:
-	::
-
-		spec.ee_pull_credentials_secret=ee-pull-secret
+	- If machine does not have access to the internet, refer to `Downloading a collection for offline use <https://docs.ansible.com/ansible/latest/collections_guide/collections_installing.html#downloading-a-collection-for-offline-use>`_.
 
 
 - To manage instances from the AWX user interface, you must have System Administrator or System Auditor permissions.
 
 
+Common topologies
+------------------
+
+Instances make up the network of devices that communicate with one another. They are the building blocks of an automation mesh. These building blocks serve as nodes in a mesh topology. There are several kinds of instances:
+
++-----------+-----------------------------------------------------------------------------------------------------------------+
+| Node Type | Description                                                                                                     |
++===========+=================================================================================================================+
+| Control   | Nodes that run persistent Ansible Automation Platform services, and delegate jobs to hybrid and execution nodes |
++-----------+-----------------------------------------------------------------------------------------------------------------+
+| Hybrid    | Nodes that run persistent Ansible Automation Platform services and execute jobs                                 |
+|           | (not applicable to operator-based installations)                                                                |
++-----------+-----------------------------------------------------------------------------------------------------------------+
+| Hop       | Used for relaying across the mesh only                                                                          |
++-----------+-----------------------------------------------------------------------------------------------------------------+
+| Execution | Nodes that run jobs delivered from control nodes (jobs submitted from the user’s Ansible automation)            |
++-----------+-----------------------------------------------------------------------------------------------------------------+
+
+Simple topology
+~~~~~~~~~~~~~~~~
+
+One of the ways to expand job capacity is to create a standalone execution node that can be added to run alongside the Kubernetes deployment of AWX. These machines will not be a part of the AWX Kubernetes cluster. The control nodes running in the cluster will connect and submit work to these machines via Receptor. The machines are registered in AWX as type "execution" instances, meaning they will only be used to run AWX jobs, not dispatch work or handle web requests as control nodes do.
+
+Hop nodes can be added to sit between the control plane of AWX and standalone execution nodes. These machines will not be a part of the AWX Kubernetes cluster and they will be registered in AWX as node type "hop", meaning they will only handle inbound and outbound traffic for otherwise unreachable nodes in a different or more strict network.
+
+Below is an example of an AWX task pod with two execution nodes. Traffic to execution node 2 flows through a hop node that is setup between it and the control plane.
+
+.. image:: ../common/images/instances_awx_task_pods_hopnode.drawio.png
+	:alt: AWX task pod with a hop node between the control plane of AWX and standalone execution nodes.
+
+
+Below are sample values used to configure each node in a simple topology:
+
+.. list-table::
+   :widths: 20 30 10 20 15
+   :header-rows: 1
+
+   * - Instance type
+     - Hostname
+     - Listener port
+     - Peers from control nodes
+     - Peers
+   * - Control plane
+     - awx-task-65d6d96987-mgn9j
+     - n/a
+     - n/a
+     - [hop node]
+   * - Hop node
+     - awx-hop-node
+     - 27199
+     - True
+     - []     
+   * - Execution node
+     - awx-example.com
+     - n/a
+     - False
+     - [hop node]  
+
+
+
+Mesh topology
+~~~~~~~~~~~~~~
+
+Mesh ingress is a feature that allows remote nodes to connect inbound to the control plane. This is especially useful when creating remote nodes in restricted networking environments that disallow inbound traffic.
+
+
+.. image:: ../common/images/instances_mesh_ingress_topology.drawio.png
+	:alt: Mesh ingress architecture showing the peering relationship between nodes.
+
+
+Below are sample values used to configure each node in a mesh ingress topology:
+
+.. list-table::
+   :widths: 20 30 10 20 15
+   :header-rows: 1
+
+   * - Instance type
+     - Hostname
+     - Listener port
+     - Peers from control nodes
+     - Peers
+   * - Control plane
+     - awx-task-65d6d96987-mgn9j
+     - n/a
+     - n/a
+     - [hop node]
+   * - Hop node
+     - awx-mesh-ingress-1
+     - 27199
+     - True
+     - []     
+   * - Execution node
+     - awx-example.com
+     - n/a
+     - False
+     - [hop node]  
+    
+
+In order to create a mesh ingress for AWX, see the `Mesh Ingress <https://ansible.readthedocs.io/projects/awx-operator/en/latest/user-guide/advanced-configuration/mesh-ingress.html>`_ chapter of the AWX Operator Documentation for information on setting up this type of topology. The last step is to create a remote execution node and add the execution node to an instance group in order for it to be used in your job execution. Whatever execution environment image used to run a playbook needs to be accessible for your remote execution node. Everything you are using in your playbook also needs to be accessible from this remote execution node.
+
+.. image:: ../common/images/instances-job-template-using-remote-execution-ig.png
+    :alt: Job template using the instance group with the execution node to run jobs.
+    :width: 1400px
+
+
+.. _ag_instances_add:
+
+Add an instance
+----------------
+
+To create an instance in AWX:
+
+1. Click **Instances** from the left side navigation menu of the AWX UI.
+
+2. In the Instances list view, click the **Add** button and the Create new Instance window opens.
+
+.. image:: ../common/images/instances_create_new.png
+    :alt: Create a new instance form.
+    :width: 1400px
+
+An instance has several attributes that may be configured:
+
+- Enter a fully qualified domain name (ping-able DNS) or IP address for your instance in the **Host Name** field (required). This field is equivalent to ``hostname`` in the API.
+- Optionally enter a **Description** for the instance
+- The **Instance State** field is auto-populated, indicating that it is being installed, and cannot be modified 
+- Optionally specify the **Listener Port** for the receptor to listen on for incoming connections. This is an open port on the remote machine used to establish inbound TCP connections. This field is equivalent to ``listener_port`` in the API. 
+- Select from the options in **Instance Type** field to specify the type you want to create. Only execution and hop nodes can be created as operator-based installations do not support hybrid nodes. This field is equivalent to ``node_type`` in the API. 
+- In the **Peers** field, select the instance hostnames you want your new instance to connect outbound to. 
+- In the **Options** fields:
+	- Check the **Enable Instance** box to make it available for jobs to run on an execution node.
+	- Check the **Managed by Policy** box to allow policy to dictate how the instance is assigned.
+	- Check the **Peers from control nodes** box to allow control nodes to peer to this instance automatically. Listener port needs to be set if this is enabled or the instance is a peer.
+
+
+
+3. Once the attributes are configured, click **Save** to proceed.
+
+Upon successful creation, the Details of the one of the created instances opens.
+
+.. image:: ../common/images/instances_create_details.png
+    :alt: Details of the newly created instance.
+    :width: 1400px
+
+.. note::
+
+	The proceeding steps 4-8 are intended to be ran from any computer that has SSH access to the newly created instance. 
+
+4. Click the download button next to the **Install Bundle** field to download the tarball that contain files to allow AWX to make proper TCP connections to the remote machine.
+
+.. image:: ../common/images/instances_install_bundle.png
+    :alt: Instance details showing the Download button in the Install Bundle field of the Details tab.
+    :width: 1400px
+
+5. Extract the downloaded ``tar.gz`` file from the location you downloaded it. The install bundle contains TLS certificates and keys, a certificate authority, and a proper Receptor configuration file. To facilitate that these files will be in the right location on the remote machine, the install bundle includes an ``install_receptor.yml`` playbook. The playbook requires the Receptor collection which can be obtained via:
+
+::
+
+	ansible-galaxy collection install -r requirements.yml
+
+6. Before running the ``ansible-playbook`` command, edit the following fields in the ``inventory.yml`` file:
+
+- ``ansible_user`` with the username running the installation
+- ``ansible_ssh_private_key_file`` to contain the filename of the private key used to connect to the instance
+
+::
+
+	---
+	all:
+	  hosts:
+	    remote-execution:
+	      ansible_host: <hostname>
+	      ansible_user: <username> # user provided
+	      ansible_ssh_private_key_file: ~/.ssh/id_rsa
+
+The content of the ``inventory.yml`` file serves as a template and contains variables for roles that are applied during the installation and configuration of a receptor node in a mesh topology. You may modify some of the other fields, or replace the file in its entirety for advanced scenarios. Refer to `Role Variables <https://github.com/ansible/receptor-collection/blob/main/README.md>`_ for more information on each variable.  
+
+7. Save the file to continue.
+
+8. Run the following command on the machine you want to update your mesh:
+
+::
+
+	ansible-playbook -i inventory.yml install_receptor.yml
+
+Wait a few minutes for the periodic AWX task to do a health check against the new instance. You may run a health check by selecting the node and clicking the **Run health check** button from its Details page at any time. Once the instances endpoint or page reports a "Ready" status for the instance, jobs are now ready to run on this machine!
+
+9. To view other instances within the same topology or associate peers, click the **Peers** tab. 
+
+.. image:: ../common/images/instances_peers_tab.png
+    :alt: "Peers" tab showing two peers.
+    :width: 1400px
+
+To associate peers with your node, click the **Associate** button to open a dialog box of instances eligible for peering.
+
+.. image:: ../common/images/instances_associate_peer.png
+    :alt:  Instances available to peer with the example hop node.
+    :width: 1400px
+
+Execution nodes can peer with either hop nodes or other execution nodes. Hop nodes can only peer with execution nodes unless you check the **Peers from control nodes** check box from the **Options** field.
+
+.. note::
+
+	If you associate or disassociate a peer, a notification will inform you to re-run the install bundle from the Peer Detail view (the :ref:`ag_topology_viewer` has the download link).
+
+    .. image:: ../common/images/instances_associate_peer_reinstallmsg.png
+      :alt: Notification to re-run the installation bundle due to change in the peering.
+
+You can remove an instance by clicking **Remove** in the Instances page, or by setting the instance ``node_state = deprovisioning`` via the API. Upon deleting, a pop-up message will appear to notify that you may need to re-run the install bundle to make sure things that were removed are no longer connected.
+
+
+10. To view a graphical representation of your updated topology, refer to the :ref:`ag_topology_viewer` section of this guide.
+
+
 Manage instances
-~~~~~~~~~~~~~~~~~~
+-----------------
 
 Click **Instances** from the left side navigation menu to access the Instances list.
 
 .. image:: ../common/images/instances_list_view.png
-	:alt: List view of instances in AWX
+    :alt: List view of instances in AWX
+    :width: 1400px
 
 The Instances list displays all the current nodes in your topology, along with relevant details:
 
@@ -75,7 +289,7 @@ The Instances list displays all the current nodes in your topology, along with r
 	- **Provisioning Failure**: a node that failed during provisioning (currently not yet supported and is subject to change in a future release)
 	- **De-provisioning Failure**: a node that failed during deprovisioning (currently not yet supported and is subject to change in a future release)
 
-- **Node Type** specifies whether the node is a control, hybrid, hop, or execution node. See :term:`node` for further detail.
+- **Node Type** specifies whether the node is a control, hop, execution node, or hybrid (not applicable to operator-based installations). See :term:`node` for further detail.
 - **Capacity Adjustment** allows you to adjust the number of forks in your nodes
 - **Used Capacity** indicates how much capacity has been used
 - **Actions** allow you to enable or disable the instance to control whether jobs can be assigned to it
@@ -83,11 +297,13 @@ The Instances list displays all the current nodes in your topology, along with r
 From this page, you can add, remove or run health checks on your nodes. Use the check boxes next to an instance to select it to remove or run a health check against. When a button is grayed-out, you do not have permission for that particular action. Contact your Administrator to grant you the required level of access. If you are able to remove an instance, you will receive a prompt for confirmation, like the one below:
 
 .. image:: ../common/images/instances_delete_prompt.png
-	:alt: Prompt for deleting instances in AWX.
+  :alt: Prompt for deleting instances in AWX
+  :width: 1400px
+
 
 .. note::
 
-	You can still remove an instance even if it is active and jobs are running on it. AWXwill attempt to wait for any jobs running on this node to complete before actually removing it.
+	You can still remove an instance even if it is active and jobs are running on it. AWX will attempt to wait for any jobs running on this node to complete before actually removing it.
 
 Click **Remove** to confirm.
 
@@ -96,7 +312,8 @@ Click **Remove** to confirm.
 If running a health check on an instance, at the top of the Details page, a message displays that the health check is in progress. 
 
 .. image:: ../common/images/instances_health_check.png
-	:alt: Health check for instances in AWX
+  :alt: Health check for instances in AWX
+  :width: 1400px
 
 Click **Reload** to refresh the instance status. 
 
@@ -104,90 +321,57 @@ Click **Reload** to refresh the instance status.
 
 	Health checks are ran asynchronously, and may take up to a minute for the instance status to update, even with a refresh. The status may or may not change after the health check. At the bottom of the Details page, a timer/clock icon displays next to the last known health check date and time stamp if the health check task is currently running.
 
-	.. image:: ../common/images/instances_health_check_pending.png
-		:alt: Health check for instance still in pending state.
+  .. image:: ../common/images/instances_health_check_pending.png
+    :alt: Health check for instance still in pending state.
 
 The example health check shows the status updates with an error on node 'one':
 
 .. image:: ../common/images/topology-viewer-instance-with-errors.png
-	:alt: Health check showing an error in one of the instances.
+  :alt: Health check showing an error in one of the instances.
+  :width: 1400px
 
 
-Add an instance
-~~~~~~~~~~~~~~~~
-  
-One of the ways to expand capacity is to create an instance, which serves as a node in your topology.
+Using a custom Receptor CA
+---------------------------
 
-1. Click **Instances** from the left side navigation menu.
+Refer to the AWX Operator Documentation, `Custom Receptor CA <https://ansible.readthedocs.io/projects/awx-operator/en/latest/user-guide/advanced-configuration/custom-receptor-certs.html>`_ for detail.
 
-2. In the Instances list view, click the **Add** button and the Create new Instance window opens.
 
-.. image:: ../common/images/instances_create_new.png
-	:alt: Create a new instance form.
+Using a private image for the default EE
+------------------------------------------
 
-An instance has several attributes that may be configured:
+Refer to the AWX Operator Documentation on `Default execution environments from private registries <https://ansible.readthedocs.io/projects/awx-operator/en/latest/user-guide/advanced-configuration/default-execution-environments-from-private-registries.html>`_ for detail.
 
-- Enter a fully qualified domain name (ping-able DNS) or IP address for your instance in the **Host Name** field (required). This field is equivalent to ``hostname`` in the API.
-- Optionally enter a **Description** for the instance
-- The **Instance State** field is auto-populated, indicating that it is being installed, and cannot be modified 
-- The **Listener Port** is pre-populated with the most optimal port, however you can change the port to one that is more appropriate for your configuration. This field is equivalent to ``listener_port`` in the API. 
-- The **Instance Type** field is auto-populated and cannot be modified. Only execution nodes can be created at this time. 
-- Check the **Enable Instance** box to make it available for jobs to run on it
 
-3. Once the attributes are configured, click **Save** to proceed.
+Troubleshooting
+----------------
 
-Upon successful creation, the Details of the created instance opens.
+If you encounter issues while setting up instances, refer to these troubleshooting tips.
 
-.. image:: ../common/images/instances_create_details.png
-	:alt: Details of the newly created instance.
+Fact cache not working
+~~~~~~~~~~~~~~~~~~~~~~~
 
-.. note::
+Make sure the system timezone on the execution node matches ``settings.TIME_ZONE`` (default is 'UTC') on AWX. Fact caching relies on comparing modified times of artifact files, and these modified times are not timezone-aware. Therefore, it is critical that the timezones of the execution nodes match AWX's timezone setting.
 
-	The proceeding steps 4-8 are intended to be ran from any computer that has SSH access to the newly created instance. 
-
-4. Click the download button next to the **Install Bundle** field to download the tarball that includes this new instance and the files relevant to install the node into the mesh.
-
-.. image:: ../common/images/instances_install_bundle.png
-	:alt: Instance details showing the Download button in the Install Bundle field of the Details tab.
-
-5. Extract the downloaded ``tar.gz`` file from the location you downloaded it. The install bundle contains yaml files, certificates, and keys that will be used in the installation process.
-
-6. Before running the ``ansible-playbook`` command, edit the following fields in the ``inventory.yml`` file:
-
-- ``ansible_user`` with the username running the installation
-- ``ansible_ssh_private_key_file`` to contain the filename of the private key used to connect to the instance
+To set the system timezone to UTC:
 
 ::
 
-	---
-	all:
-	  hosts:
-	    remote-execution:
-	      ansible_host: 18.206.206.34
-	      ansible_user: <username> # user provided
-	      ansible_ssh_private_key_file: ~/.ssh/id_rsa
+	ln -s /usr/share/zoneinfo/Etc/UTC /etc/localtime
 
-The content of the ``inventory.yml`` file serves as a template and contains variables for roles that are applied during the installation and configuration of a receptor node in a mesh topology. You may modify some of the other fields, or replace the file in its entirety for advanced scenarios. Refer to `Role Variables <https://github.com/ansible/receptor-collection/blob/main/README.md>`_ for more information on each variable.  
 
-7. Save the file to continue.
+Permission denied errors
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-8. Run the following command on the machine you want to update your mesh:
+Jobs may fail with the following error, or similar:
 
 ::
 
-	ansible-playbook -i inventory.yml install_receptor.yml
+	"msg":"exec container process `/usr/local/bin/entrypoint`: Permission denied"
 
 
-9. To view other instances within the same topology, click the **Peers** tab associated with the control node. 
+For RHEL-based machines, this could be due to SELinux that is enabled on the system. You can pass these ``extra_settings`` container options to override SELinux protections:
 
-.. note::
+::
 
-	You will only be able to view peers of the control plane nodes at this time, which are the execution nodes. Since you are limited to creating execution nodes in this release, you will be unable to create or view peers of execution nodes.  
-
-
-.. image:: ../common/images/instances_peers_tab.png
-	:alt: "Peers" tab showing two peers.
-
-You may run a health check by selecting the node and clicking the **Run health check** button from its Details page.
-
-10. To view a graphical representation of your updated topology, refer to the :ref:`ag_topology_viewer` section of this guide.
+	DEFAULT_CONTAINER_RUN_OPTIONS = ['--network', 'slirp4netns:enable_ipv6=true', '--security-opt', 'label=disable']

docs/docsite/rst/administration/ldap_auth.rst

@@ -7,6 +7,7 @@ Setting up LDAP Authentication
    single: LDAP
    pair: authentication; LDAP
    
+This chapter describes how to integrate LDAP authentication with AWX.
 
 .. note::
 

docs/docsite/rst/administration/topology_viewer.rst

@@ -19,7 +19,7 @@ The Topology View opens and displays a graphic representation of how each recept
 .. image:: ../common/images/topology-viewer-initial-view.png
 
 
-2. To adjust the zoom levels, or manipulate the graphic views, use the control buttons on the upper right-hand corner of the window.
+2. To adjust the zoom levels, refresh the current view, or manipulate the graphic views, use the control buttons on the upper right-hand corner of the window.
 
 .. image:: ../common/images/topology-viewer-view-controls.png
 

docs/docsite/rst/release_notes/known_issues.rst

@@ -146,7 +146,7 @@ If you have a VMware instance that uses a self-signed certificate, then you will
 
 .. code-block:: text
 
-   "source_vars": "---\nvalidate_certs: False",
+   "source_vars": ---validate_certs: False
 
 You can set this in inventory source for VMware vCenter as follows:
 

docs/docsite/rst/release_notes/relnotes.rst

@@ -11,19 +11,13 @@ Release Notes
    pair: release notes; v23.3.0
    pair: release notes; v23.3.1
    pair: release notes; v23.4.0
+   pair: release notes; v23.5.0
+   pair: release notes; v23.5.1
+   pair: release notes; v23.6.0
+   pair: release notes; v23.7.0
+   pair: release notes; v23.8.0
+   pair: release notes; v23.8.1
 
 
-For versions older than 23.0.0, refer to `AWX Release Notes <https://github.com/ansible/awx/releases>`_.
+Refer to `AWX Release Notes <https://github.com/ansible/awx/releases>`_.
 
-
-- See `What's Changed for 23.4.0 <https://github.com/ansible/awx/releases/tag/23.4.0>`_.
-
-- See `What's Changed for 23.3.1 <https://github.com/ansible/awx/releases/tag/23.3.1>`_.
-
-- See `What's Changed for 23.3.0 <https://github.com/ansible/awx/releases/tag/23.3.0>`_.
-
-- See `What's Changed for 23.2.0 <https://github.com/ansible/awx/releases/tag/23.2.0>`_.
-
-- See `What's Changed for 23.1.0 <https://github.com/ansible/awx/releases/tag/23.1.0>`_.
-
-- See `What's Changed for 23.0.0 <https://github.com/ansible/awx/releases/tag/23.0.0>`_.

docs/docsite/rst/rest_api/_swagger/swagger.py

@@ -35,12 +35,8 @@ def assets(app, exception):
         _, extension = os.path.splitext(asset)
         if extension in ('py', 'pyc'):
             continue
-        if not exception and os.path.exists(
-            os.path.join(app.outdir, '_static')
-        ):
-            copyfile(
-                os.path.join(here, asset),
-                os.path.join(app.outdir, '_static', asset))
+        if not exception and os.path.exists(os.path.join(app.outdir, '_static')):
+            copyfile(os.path.join(here, asset), os.path.join(app.outdir, '_static', asset))
 
 
 def setup(app):

docs/docsite/rst/rest_api/authentication.rst

@@ -89,8 +89,6 @@ Example with curl:
 
 .. code-block:: text
 
-   curl -X GET -H 'Authorization: Basic dXNlcjpwYXNzd29yZA==’ https://<awx-host>/api/v2/credentials -k -L
-
    # the --user flag adds this Authorization header for us
    curl -X GET --user 'user:password' https://<awx-host>/api/v2/credentials -k -L
 

docs/docsite/rst/userguide/credential_plugins.rst

@@ -10,14 +10,15 @@ Secret Management System
    
 Users and admins upload machine and cloud credentials so that automation can access machines and external services on their behalf. By default, sensitive credential values (such as SSH passwords, SSH private keys, API tokens for cloud services) are stored in the database after being encrypted. With external credentials backed by credential plugins, you can map credential fields (like a password or an SSH Private key) to values stored in a :term:`secret management system` instead of providing them to AWX directly. AWX provides a secret management system that include integrations for:
 
-- Centrify Vault Credential Provider Lookup
-- CyberArk Central Credential Provider Lookup (CCP)
-- CyberArk Conjur Secrets Manager Lookup
-- HashiCorp Vault Key-Value Store (KV)
-- HashiCorp Vault SSH Secrets Engine
-- Microsoft Azure Key Management System (KMS)
-- Thycotic DevOps Secrets Vault
-- Thycotic Secret Server
+- :ref:`ug_credentials_aws_lookup`
+- :ref:`ug_credentials_centrify`
+- :ref:`ug_credentials_cyberarkccp`
+- :ref:`ug_credentials_cyberarkconjur`
+- :ref:`ug_credentials_hashivault` (KV)
+- :ref:`ug_credentials_hashivaultssh`
+- :ref:`ug_credentials_azurekeyvault` (KMS)
+- :ref:`ug_credentials_thycoticvault`
+- :ref:`ug_credentials_thycoticserver`
 
 These external secret values will be fetched prior to running a playbook that needs them. For more information on specifying these credentials in the User Interface, see :ref:`ug_credentials`.
 
@@ -49,11 +50,92 @@ Use the AWX User Interface to configure and use each of the supported 3-party se
 .. image:: ../common/images/credentials-link-credential-prompt.png 
    :alt: Credential section of the external secret management system dialog
 
-4. Select the credential you want to link to, and click **Next**. This takes you to the **Metadata** tab of the input source. This example shows the Metadata prompt for HashiVault Secret Lookup. Metadata is specific to the input source you select. See the :ref:`ug_metadata_creds_inputs` table for details.
+4. Select the credential you want to link to, and click **Next**. This takes you to the **Metadata** tab of the input source. Metadata is specific to the input source you select:
+
+.. list-table::
+   :widths: 10 10 25
+   :width: 1400px
+   :header-rows: 1
+
+   * - Input Source 
+     - Metadata
+     - Description
+   * - *AWS Secrets Manager*
+     - AWS Secrets Manager Region (required)
+     - The region where the secrets manager is located.
+   * - 
+     - AWS Secret Name (Required)
+     - Specify the AWS secret name that was generated by the AWS access key.
+   * - *Centrify Vault Credential Provider Lookup*
+     - Account Name (Required)
+     - Name of the system account or domain associated with Centrify Vault.
+   * - 
+     - System Name
+     - Specify the name used by the Centrify portal.
+   * - *CyberArk Central Credential Provider Lookup*
+     - Object Query (Required)
+     - Lookup query for the object.
+   * - 
+     - Object Query Format
+     - Select ``Exact`` for a specific secret name, or ``Regexp`` for a secret that has a dynamically generated name.
+   * - 
+     - Object Property
+     - Specifies the name of the property to return (e.g., ``UserName``, ``Address``, etc.) other than the default of ``Content``.
+   * -
+     - Reason
+     - If required per the object's policy, supply a reason for checking out the secret, as CyberArk logs those.
+   * - *CyberArk Conjur Secrets Lookup*
+     - Secret Identifier
+     - The identifier for the secret.
+   * - 
+     - Secret Version
+     - Specify a version of the secret, if necessary, otherwise, leave it empty to use the latest version.
+   * - *HashiVault Secret Lookup*
+     - Name of Secret Backend
+     - Specify the name of the KV backend to use. Leave it blank to use the first path segment of the **Path to Secret** field instead.
+   * - 
+     - Path to Secret (required)
+     - Specify the path to where the secret information is stored; for example, ``/path/username``.
+   * - 
+     - Key Name (required)
+     - Specify the name of the key to look up the secret information.
+   * - 
+     - Secret Version (V2 Only)
+     - Specify a version if necessary, otherwise, leave it empty to use the latest version.
+   * - *HashiCorp Signed SSH*
+     - Unsigned Public Key (required)
+     - Specify the public key of the cert you want to get signed. It needs to be present in the authorized keys file of the target host(s).
+   * -
+     - Path to Secret (required)
+     - Specify the path to where the secret information is stored; for example, ``/path/username``.
+   * - 
+     - Role Name (required)
+     - A role is a collection of SSH settings and parameters that are stored in Hashi vault. Typically, you can specify a couple of them with different privileges, timeouts, etc. So you could have a role that is allowed to get a cert signed for root, and other less privileged ones, for example.
+   * - 
+     - Valid Principals
+     - Specify a user (or users) other than the default, that you are requesting vault to authorize the cert for the stored key. Hashi vault has a default user for whom it signs (e.g., ec2-user).
+   * - *Azure KMS*
+     - Secret Name (required)
+     - The actual name of the secret as it is referenced in Azure's Key vault app.
+   * - 
+     - Secret Version
+     - Specify a version of the secret, if necessary, otherwise, leave it empty to use the latest version.
+   * - *Thycotic DevOps Secrets Vault*
+     - Secret Path (required)
+     - Specify the path to where the secret information is stored (e.g., /path/username).
+   * - *Thycotic Secret Server*
+     - Secret ID (required)
+     - The identifier for the secret.
+   * - 
+     - Secret Field
+     - Specify the field to be used from the secret.
+
+This example shows the Metadata prompt for HashiVault Secret Lookup.  
 
 .. image:: ../common/images/credentials-link-metadata-prompt.png
    :alt: Metadata section of the external secret management system dialog
 
+
 5. Click **Test** to verify connection to the secret management system. If the lookup is unsuccessful, an error message like this one displays:
 
 .. image:: ../common/images/credentials-link-metadata-test-error.png
@@ -65,133 +147,37 @@ Use the AWX User Interface to configure and use each of the supported 3-party se
 
 8. Click **Save** when done.
 
-.. _ug_metadata_creds_inputs:
 
-Metadata for credential input sources
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+.. _ug_credentials_aws_lookup:
 
-**Centrify Vault Credential Provider Lookup**
+AWS Secrets Manager Lookup
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. index::
+   pair: credential types; AWS
 
-.. list-table::
-   :widths: 25 50
-   :header-rows: 1
+This plugin allows AWS to be used as a credential input source to pull secrets from AWS SecretsManager. `AWS Secrets Manager <https://aws.amazon.com/secrets-manager/>`_ provides similar service to :ref:`ug_credentials_azurekeyvault`, and the AWS collection provides a lookup plugin for it. 
 
-   * - Metadata
-     - Description
-   * - Account Name (Required)
-     - Name of the system account or domain associated with Centrify Vault.
-   * - System Name
-     - Specify the name used by the Centrify portal.
+When **AWS Secrets Manager lookup** is selected for **Credential Type**, provide the following attributes to properly configure your lookup:
 
-**CyberArk Central Credential Provider Lookup**
+- **AWS Access Key** (required): provide the access key used for communicating with AWS' key management system
+- **AWS Secret Key** (required): provide the secret as obtained by the AWS IAM console
 
-.. list-table::
-   :widths: 25 50
-   :header-rows: 1
 
-   * - Metadata
-     - Description
-   * - Object Query (Required)
-     - Lookup query for the object.
-   * - Object Query Format
-     - Select ``Exact`` for a specific secret name, or ``Regexp`` for a secret that has a dynamically generated name.
-   * - Object Property
-     - Specifies the name of the property to return (e.g., ``UserName``, ``Address``, etc.) other than the default of ``Content``.
-   * - Reason
-     - If required per the object's policy, supply a reason for checking out the secret, as CyberArk logs those.
+Below shows an example of a configured AWS Secret Manager credential.
 
-**CyberArk Conjur Secrets Lookup**
+.. image:: ../common/images/credentials-create-aws-secret-credential.png
+   :width: 1400px
+   :alt: Example new AWS Secret Manager credential lookup dialog
 
-.. list-table::
-   :widths: 25 50
-   :header-rows: 1
-
-   * - Metadata
-     - Description
-   * - Secret Identifier
-     - The identifier for the secret.
-   * - Secret Version
-     - Specify a version of the secret, if necessary, otherwise, leave it empty to use the latest version.
-
-**HashiVault Secret Lookup**
-
-.. list-table::
-   :widths: 25 50
-   :header-rows: 1
-
-   * - Metadata
-     - Description
-   * - Name of Secret Backend
-     - Specify the name of the KV backend to use. Leave it blank to use the first path segment of the **Path to Secret** field instead.
-   * - Path to Secret (required)
-     - Specify the path to where the secret information is stored; for example, ``/path/username``.
-   * - Key Name (required)
-     - Specify the name of the key to look up the secret information.
-   * - Secret Version (V2 Only)
-     - Specify a version if necessary, otherwise, leave it empty to use the latest version.
-
-**HashiCorp Signed SSH**
-
-.. list-table::
-   :widths: 25 50
-   :header-rows: 1
-
-   * - Metadata
-     - Description
-   * - Unsigned Public Key (required)
-     - Specify the public key of the cert you want to get signed. It needs to be present in the authorized keys file of the target host(s).
-   * - Path to Secret (required)
-     - Specify the path to where the secret information is stored; for example, ``/path/username``.
-   * - Role Name (required)
-     - A role is a collection of SSH settings and parameters that are stored in Hashi vault. Typically, you can specify a couple of them with different privileges, timeouts, etc. So you could have a role that is allowed to get a cert signed for root, and other less privileged ones, for example.
-   * - Valid Principals
-     - Specify a user (or users) other than the default, that you are requesting vault to authorize the cert for the stored key. Hashi vault has a default user for whom it signs (e.g., ec2-user).
-
-**Azure KMS**
-
-.. list-table::
-   :widths: 25 50
-   :header-rows: 1
-
-   * - Metadata
-     - Description
-   * - Secret Name (required)
-     - The actual name of the secret as it is referenced in Azure's Key vault app.
-   * - Secret Version
-     - Specify a version of the secret, if necessary, otherwise, leave it empty to use the latest version.
-
-**Thycotic DevOps Secrets Vault**
-
-.. list-table::
-   :widths: 25 50
-   :header-rows: 1
-
-   * - Metadata
-     - Description
-   * - Secret Path (required)
-     - Specify the path to where the secret information is stored (e.g., /path/username).
-
-**Thycotic Secret Server**
-
-.. list-table::
-   :widths: 25 50
-   :header-rows: 1
-
-   * - Metadata
-     - Description
-   * - Secret ID (required)
-     - The identifier for the secret.
-   * - Secret Field
-     - Specify the field to be used from the secret.
 
 .. _ug_credentials_centrify:
 
 Centrify Vault Credential Provider Lookup
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 .. index::
    pair: credential types; Centrify
 
-You need the Centrify Vault web service running to store secrets in order for this integration to work. When **Centrify Vault Credential Provider Lookup** is selected for **Credential Type**, provide the following metadata to properly configure your lookup:
+You need the Centrify Vault web service running to store secrets in order for this integration to work. When **Centrify Vault Credential Provider Lookup** is selected for **Credential Type**, provide the following attributes to properly configure your lookup:
 
 - **Centrify Tenant URL** (required): provide the URL used for communicating with Centrify's secret management system
 - **Centrify API User** (required): provide the username
@@ -208,12 +194,12 @@ Below shows an example of a configured CyberArk AIM credential.
 .. _ug_credentials_cyberarkccp:
 
 CyberArk Central Credential Provider (CCP) Lookup
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 .. index::
    single: CyberArk CCP
    pair: credential; CyberArk CCP
 
-You need the CyberArk Central Credential Provider web service running to store secrets in order for this integration to work. When **CyberArk Central Credential Provider Lookup** is selected for **Credential Type**, provide the following metadata to properly configure your lookup:
+You need the CyberArk Central Credential Provider web service running to store secrets in order for this integration to work. When **CyberArk Central Credential Provider Lookup** is selected for **Credential Type**, provide the following attributes to properly configure your lookup:
 
 - **CyberArk CCP URL** (required): provide the URL used for communicating with CyberArk CCP's secret management system; must include URL scheme (http, https, etc.)
 - **Web Service ID**: optionally specify the identifier for the web service; leaving it blank defaults to AIMWebService
@@ -230,14 +216,14 @@ Below shows an example of a configured CyberArk CCP credential.
 .. _ug_credentials_cyberarkconjur:
 
 CyberArk Conjur Secrets Manager Lookup
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 .. index::
    single: CyberArk Conjur
    pair: credential; CyberArk Conjur
 
 With a Conjur Cloud tenant available to target, configure the CyberArk Conjur Secrets Lookup external management system credential plugin as documented.
 
-When **CyberArk Conjur Secrets Manager Lookup** is selected for **Credential Type**, provide the following metadata to properly configure your lookup:
+When **CyberArk Conjur Secrets Manager Lookup** is selected for **Credential Type**, provide the following attributes to properly configure your lookup:
 
 - **Conjur URL** (required): provide the URL used for communicating with CyberArk Conjur's secret management system; must include URL scheme (http, https, etc.)
 - **API Key** (required): provide the key given by your Conjur admin
@@ -253,46 +239,59 @@ Below shows an example of a configured CyberArk Conjur credential.
 .. _ug_credentials_hashivault:
 
 HashiCorp Vault Secret Lookup
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 .. index::
    single: HashiCorp Secret Lookup
    pair: credential; HashiCorp KV
 
-When **HashiCorp Vault Secret Lookup** is selected for **Credential Type**, provide the following metadata to properly configure your lookup:
+When **HashiCorp Vault Secret Lookup** is selected for **Credential Type**, provide the following attributes to properly configure your lookup:
 
 - **Server URL** (required): provide the URL used for communicating with HashiCorp Vault's secret management system
 - **Token**: specify the access token used to authenticate HashiCorp's server
 - **CA Certificate**: specify the CA certificate used to verify HashiCorp's server
-- **Approle Role_ID**: specify the ID for Approle authentication
+- **Approle Role_ID**: specify the ID if using Approle for authentication
 - **Approle Secret_ID**: specify the corresponding secret ID for Approle authentication
 - **Client Certificate**: specify a PEM-encoded client certificate when using the TLS auth method including any required intermediate certificates expected by Vault
 - **Client Certificate Key**: specify a PEM-encoded certificate private key when using the TLS auth method
 - **TLS Authentication Role**: specify the role or certificate name in Vault that corresponds to your client certificate when using the TLS auth method. If it is not provided, Vault will attempt to match the certificate automatically
 - **Namespace name** specify the namespace name (Vault Enterprise only)
 - **Kubernetes role** specify the role name when using Kubernetes authentication
+- **Username**: enter the username of the user to be used to authenticate this service
+- **Password**: enter the password associated with the user to authenticate this service
 - **Path to Auth**: specify a path if other than the default path of ``/approle``
 - **API Version** (required): select v1 for static lookups and v2 for versioned lookups
 
-For more detail about the Approle auth method and its fields, refer to the `Vault documentation for Approle Auth Method <https://www.vaultproject.io/docs/auth/approle>`_.
 
-For more detail about the Kubernetes auth method and its fields, refer to the `Vault documentation for Kubernetes auth method <https://developer.hashicorp.com/vault/docs/auth/kubernetes>` _.
+For more detail about the Approle auth method and its fields, refer to the `Vault documentation for Approle Auth Method <https://developer.hashicorp.com/vault/docs/auth/approle>`_.
 
-For more detail about the TLS certificate auth method and its fields, refer to the `Vault documentation for TLS certificates auth method <https://developer.hashicorp.com/vault/docs/auth/cert>` _.
+LDAP authentication requires LDAP to be configured in HashiCorp's Vault UI. A policy may be added to the user if they want access to a specific engine created. As long as the bind is set properly, the user should be able to successfully authenticate. Cubbyhole is the name of the default secret mount. If you have proper permissions, you can create other mounts and write key values to those. For more detail about the LDAP auth method and its fields, refer to the `Vault documentation for LDAP auth method <https://developer.hashicorp.com/vault/docs/auth/ldap>`_.
 
-Below shows an example of a configured HashiCorp Vault Secret Lookup credential.
+For more detail about the userpass auth method and its fields, refer to the `Vault documentation for userpass auth method <https://developer.hashicorp.com/vault/docs/auth/userpass>`_.
+
+For more detail about the Kubernetes auth method and its fields, refer to the `Vault documentation for Kubernetes auth method <https://developer.hashicorp.com/vault/docs/auth/kubernetes>`_.
+
+For more detail about the TLS certificate auth method and its fields, refer to the `Vault documentation for TLS certificates auth method <https://developer.hashicorp.com/vault/docs/auth/cert>`_.
+
+Below shows an example of a configured HashiCorp Vault Secret Lookup  credential for LDAP.
 
 .. image:: ../common/images/credentials-create-hashicorp-kv-credential.png 
    :alt: Example new HashiCorp Vault Secret lookup dialog
 
+To test the lookup, create another credential that uses the HashiCorp Vault lookup. The example below shows the attributes for a machine credential configured to look up HashiCorp Vault secret credentials:
+
+.. image:: ../common/images/credentials-machine-test-hashicorp-metadata.png 
+   :alt: Example machine credential lookup metadata for HashiCorp Vault.
+
+
 .. _ug_credentials_hashivaultssh:
 
 HashiCorp Vault Signed SSH
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 .. index::
    single: HashiCorp SSH Secrets Engine
    pair: credential; HashiCorp SSH Secrets Engine
 
-When **HashiCorp Vault Signed SSH** is selected for **Credential Type**, provide the following metadata to properly configure your lookup:
+When **HashiCorp Vault Signed SSH** is selected for **Credential Type**, provide the following attributes to properly configure your lookup:
 
 - **Server URL** (required): provide the URL used for communicating with HashiCorp Signed SSH's secret management system
 - **Token**: specify the access token used to authenticate HashiCorp's server
@@ -304,13 +303,15 @@ When **HashiCorp Vault Signed SSH** is selected for **Credential Type**, provide
 - **TLS Authentication Role**: specify the role or certificate name in Vault that corresponds to your client certificate when using the TLS auth method. If it is not provided, Vault will attempt to match the certificate automatically
 - **Namespace name** specify the namespace name (Vault Enterprise only)
 - **Kubernetes role** specify the role name when using Kubernetes authentication
+- **Username**: enter the username of the user to be used to authenticate this service
+- **Password**: enter the password associated with the user to authenticate this service
 - **Path to Auth**: specify a path if other than the default path of ``/approle``
 
-For more detail about the Approle auth method and its fields, refer to the `Vault documentation for Approle Auth Method <https://www.vaultproject.io/docs/auth/approle>`_.
+For more detail about the Approle auth method and its fields, refer to the `Vault documentation for Approle Auth Method <https://developer.hashicorp.com/vault/docs/auth/approle>`_.
 
-For more detail about the Kubernetes auth method and its fields, refer to the `Vault documentation for Kubernetes auth method <https://developer.hashicorp.com/vault/docs/auth/kubernetes>` _.
+For more detail about the Kubernetes auth method and its fields, refer to the `Vault documentation for Kubernetes auth method <https://developer.hashicorp.com/vault/docs/auth/kubernetes>`_.
 
-For more detail about the TLS certificate auth method and its fields, refer to the `Vault documentation for TLS certificates auth method <https://developer.hashicorp.com/vault/docs/auth/cert>` _.
+For more detail about the TLS certificate auth method and its fields, refer to the `Vault documentation for TLS certificates auth method <https://developer.hashicorp.com/vault/docs/auth/cert>`_.
 
 Below shows an example of a configured HashiCorp SSH Secrets Engine credential.
 
@@ -320,13 +321,13 @@ Below shows an example of a configured HashiCorp SSH Secrets Engine credential.
 .. _ug_credentials_azurekeyvault:
 
 Microsoft Azure Key Vault
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 .. index::
    single: MS Azure KMS
    pair: credential; MS Azure KMS
    triple: credential; Azure; KMS
 
-When **Microsoft Azure Key Vault** is selected for **Credential Type**, provide the following metadata to properly configure your lookup:
+When **Microsoft Azure Key Vault** is selected for **Credential Type**, provide the following attributes to properly configure your lookup:
 
 - **Vault URL (DNS Name)** (required): provide the URL used for communicating with MS Azure's key management system
 - **Client ID** (required): provide the identifier as obtained by the Azure Active Directory
@@ -342,12 +343,12 @@ Below shows an example of a configured Microsoft Azure KMS credential.
 .. _ug_credentials_thycoticvault:
 
 Thycotic DevOps Secrets Vault
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 .. index::
    single: Thycotic DevOps Secrets Vault
    pair: credential; Thycotic DevOps Secrets Vault
 
-When **Thycotic DevOps Secrets Vault** is selected for **Credential Type**, provide the following metadata to properly configure your lookup:
+When **Thycotic DevOps Secrets Vault** is selected for **Credential Type**, provide the following attributes to properly configure your lookup:
 
 - **Tenant** (required): provide the URL used for communicating with Thycotic's secret management system
 - **Top-level Domain (TLD)** : provide the top-level domain designation (e.g., com, edu, org) associated with the secret vault you want to integrate
@@ -364,12 +365,12 @@ Below shows an example of a configured Thycotic DevOps Secrets Vault credential.
 .. _ug_credentials_thycoticserver:
 
 Thycotic Secret Server
-^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~
 .. index::
    single: Thycotic Secret Server
    pair: credential; Thycotic Secret Server
 
-When **Thycotic Secrets Server** is selected for **Credential Type**, provide the following metadata to properly configure your lookup:
+When **Thycotic Secrets Server** is selected for **Credential Type**, provide the following attributes to properly configure your lookup:
 
 - **Secret Server URL** (required): provide the URL used for communicating with the Thycotic Secrets Server management system
 - **Username** (required): specify the authenticated user for this service

docs/docsite/rst/userguide/credentials.rst

@@ -128,7 +128,7 @@ The following credential types are supported with AWX:
 .. contents::
     :local:
 
-The credential types associated with Centrify, CyberArk, HashiCorp Vault, Microsoft Azure Key Management System (KMS), and Thycotic are part of the credential plugins capability that allows an external system to lookup your secrets information. See the :ref:`ug_credential_plugins` section for further detail.
+The credential types associated with AWS Secrets Manager, Centrify, CyberArk, HashiCorp Vault, Microsoft Azure Key Management System (KMS), and Thycotic are part of the credential plugins capability that allows an external system to lookup your secrets information. See the :ref:`ug_credential_plugins` section for further detail.
 
 
 .. _ug_credentials_aws:
@@ -166,6 +166,10 @@ AWX provides support for EC2 STS tokens (sometimes referred to as IAM STS creden
 
   To use implicit IAM role credentials, do not attach AWS cloud credentials in AWX when relying on IAM roles to access the AWS API.  While it may seem to make sense to attach your AWS cloud credential to your job template, doing so will force the use of your AWS credentials and will not "fall through" to use your IAM role credentials (this is due to the use of the boto library.)
 
+AWS Secrets Manager 
+^^^^^^^^^^^^^^^^^^^^^
+This is considered part of the secret management capability. See :ref:`ug_credentials_aws_lookup` for more detail.
+
 
 Ansible Galaxy/Automation Hub API Token
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -642,6 +646,39 @@ Source Control credentials have several attributes that may be configured:
     If you are using a GitHub account for a Source Control credential and you have 2FA (Two Factor Authentication) enabled on your account, you will need to use your Personal Access Token in the password field rather than your account password. 
 
 
+.. _ug_credentials_terraform:
+
+Terraform backend configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. index::
+   pair: credential types; Terraform
+   pair: backend configuration; Terraform
+
+
+Terraform is a HashiCorp tool used to automate various infrastructure tasks. Select this credential type to enable synchronization with the Terraform inventory source.
+
+The Terraform credential requires the **Backend configuration** attribute which should contain the data from a `Terraform backend block <https://developer.hashicorp.com/terraform/language/settings/backends/configuration>`_. You can paste, drag a file, browse to upload a file, or click the (|key icon|) button to populate the field from an external :ref:`ug_credential_plugins`. An example configuration for an S3 backend:
+
+.. |key icon| image:: ../common/images/key-mgmt-button.png
+    :alt: Credentials - create Terraform backend configuration credential form
+
+::
+
+    bucket = "my-terraform-state-bucket"
+    key = "path/to/terraform-state-file"
+    region = "us-east-1"
+    access_key = "my-aws-access-key"
+    secret_key = "my-aws-secret-access-key"
+
+|Credentials - create terraform credential|
+
+.. |Credentials - create terraform credential| image:: ../common/images/credentials-create-terraform-credential.png
+    :alt: Credentials - create Terraform backend configuration credential form
+
+Saving it stores the file path to the backend configuration in an environment variable ``TF_BACKEND_CONFIG_FILE`` that is made available to any job with the credential attached.
+
+
 Thycotic DevOps Secrets Vault
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 This is considered part of the secret management capability. See :ref:`ug_credentials_thycoticvault` for more detail.

docs/docsite/rst/userguide/glossary.rst

@@ -90,18 +90,6 @@ Glossary
     Node
         A node corresponds to entries in the instance database model, or the ``/api/v2/instances/`` endpoint, and is a machine participating in the cluster / mesh. The unified jobs API reports ``awx_node`` and ``execution_node`` fields. The execution node is where the job runs, and AWX node interfaces between the job and server functions.
 
-        +-----------+------------------------------------------------------------------------------------------------------+
-        | Node Type | Description                                                                                          |
-        +===========+======================================================================================================+
-        | Control   | Nodes that run persistent |aap| services, and delegate jobs to hybrid and execution nodes            |
-        +-----------+------------------------------------------------------------------------------------------------------+
-        | Hybrid    | Nodes that run persistent |aap| services and execute jobs                                            |
-        +-----------+------------------------------------------------------------------------------------------------------+
-        | Hop       | Used for relaying across the mesh only                                                               |
-        +-----------+------------------------------------------------------------------------------------------------------+
-        | Execution | Nodes that run jobs delivered from control nodes (jobs submitted from the user's Ansible automation) |
-        +-----------+------------------------------------------------------------------------------------------------------+
-
     Notification Template
         An instance of a notification type (Email, Slack, Webhook, etc.) with a name, description, and a defined configuration.
 

docs/docsite/rst/userguide/inventories.rst

@@ -481,6 +481,7 @@ Inventory updates use dynamically-generated YAML files which are parsed by their
 - :ref:`ug_source_openstack`
 - :ref:`ug_source_rhv`
 - :ref:`ug_source_rhaap`
+- :ref:`ug_source_terraform`
 
 
 Newly created configurations for inventory sources will contain the default plugin configuration values. If you want your newly created inventory sources to match the output of legacy sources, you must apply a specific set of configuration values for that source. To ensure backward compatibility, AWX uses "templates" for each of these sources to force the output of inventory plugins into the legacy format. Refer to :ref:`ir_inv_plugin_templates_reference` section of this guide for each source and their respective templates to help you migrate to the new style inventory plugin output.
@@ -1084,6 +1085,41 @@ Red Hat Ansible Automation Platform
 
 4. Use the **Source Variables** field to override variables used by the ``controller`` inventory plugin. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. 
 
+
+.. _ug_source_terraform:
+
+Terraform State
+~~~~~~~~~~~~~~~~
+
+.. index::
+   pair: inventories; Terraform
+   pair: inventory source; Terraform state
+
+
+This inventory source uses the `terraform_state <https://github.com/ansible-collections/cloud.terraform/blob/main/plugins/inventory/terraform_state.py>`_ inventory plugin from the `cloud.terraform <https://github.com/ansible-collections/cloud.terraform>`_ collection. The plugin will parse a terraform state file and add hosts for AWS EC2, GCE, and Azure instances.
+
+1. To configure this type of sourced inventory, select **Terraform State** from the Source field.
+
+2. The Create new source window expands with the required **Credential** field. Choose from an existing Terraform backend Credential. For more information, refer to :ref:`ug_credentials`.
+
+3. You can optionally specify the verbosity, host filter, enabled variable/value, and update options as described in the main procedure for :ref:`adding a source <ug_add_inv_common_fields>`. For Terraform, enable **Overwrite** and **Update on launch** options.  
+
+4. Use the **Source Variables** field to override variables used by the ``controller`` inventory plugin. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. For more information on these variables, see the `terraform_state <https://github.com/ansible-collections/cloud.terraform/blob/main/plugins/inventory/terraform_state.py>`_ file for detail.
+
+  The ``backend_type`` variable is required by the Terraform state inventory plugin. This should match the remote backend configured in the Terraform backend credential, here is an example for an Amazon S3 backend:
+
+  ::
+
+    ---
+    backend_type: s3
+
+5. Enter an |ee| in the **Execution Environment** field that contains a Terraform binary. This is required for the inventory plugin to run the Terraform commands that read inventory data from the Terraform state file. Refer to the `Terraform EE readme <https://github.com/ansible-cloud/terraform_ee>`_ that contains an example |ee| configuration with a Terraform binary.
+
+  .. image:: ../common/images/inventories-create-source-terraform-example.png
+
+6. To add hosts for AWS EC2, GCE, and Azure instances, the Terraform state file in the backend must contain state for resources already deployed to EC2, GCE, or Azure. Refer to each of the Terraform providers' respective documentation to provision instances.
+
+
 .. _ug_customscripts:
 
 Export old inventory scripts

docs/docsite/rst/userguide/job_templates.rst

@@ -110,7 +110,7 @@ To create a new job template:
      - * If selected, even if a default value is supplied, you will be prompted upon launch to supply additional labels if needed. 
        * You will not be able to delete existing labels - clicking (|x-circle|) only removes the newly added labels, not existing default labels.
    * - **Variables**
-     - * Pass extra command line variables to the playbook. This is the "-e" or "--extra-vars" command line parameter for ansible-playbook that is documented in the Ansible documentation at `Passing Variables on the Command Line <https://docs.ansible.com/ansible/latest/reference_appendices/general_precedence.html>`_.
+     - * Pass extra command line variables to the playbook. This is the "-e" or "--extra-vars" command line parameter for ansible-playbook that is documented in the Ansible documentation at `Defining variables at runtime <https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#defining-variables-at-runtime>`_.
        * Provide key/value pairs using either YAML or JSON. These variables have a maximum value of precedence and overrides other variables specified elsewhere. An example value might be:
 
         ::

docs/docsite/rst/userguide/security.rst

@@ -202,7 +202,7 @@ The following table lists the RBAC system roles and a brief description of the h
 +-----------------------------------------------------------------------+------------------------------------------------------------------------------------------+
 | Execute Role - Job Templates                                          | Runs assigned Job Template                                                               |
 +-----------------------------------------------------------------------+------------------------------------------------------------------------------------------+
-| Member Role - Organization, Team                                      | Manages all of the settings associated with that Organization or Team                    |
+| Member Role - Organization, Team                                      | User is a member of a defined Organization or Team                                       |
 +-----------------------------------------------------------------------+------------------------------------------------------------------------------------------+
 | Read Role - Organizations, Teams, Inventory, Projects, Job Templates  | Views all aspects of a defined Organization, Team, Inventory, Project, or Job Template   |
 +-----------------------------------------------------------------------+------------------------------------------------------------------------------------------+

docs/execution_environments.md

@@ -4,7 +4,7 @@ All jobs use container isolation for environment consistency and security.
 Compliant images are referred to as Execution Environments (EE)s.
 
 For more information about the EE technology as well as how to build and test EEs, see:
-- [Getting started with Execution Environments guide](https://docs.ansible.com/ansible/devel/getting_started_ee/index.html)
+- [Getting started with Execution Environments guide](https://ansible.readthedocs.io/en/latest/getting_started_ee/index.html)
 - [Ansible Builder documentation](https://ansible.readthedocs.io/projects/builder/en/latest/)
 
 The Execution Environment model has an `image` field for the image identifier which will be used by jobs.

docs/execution_nodes.md

@@ -1,112 +0,0 @@
-# Adding execution nodes to AWX
-
-Stand-alone execution nodes can be added to run alongside the Kubernetes deployment of AWX. These machines will not be a part of the AWX Kubernetes cluster. The control nodes running in the cluster will connect and submit work to these machines via Receptor. The machines be registered in AWX as type "execution" instances, meaning they will only be used to run AWX Jobs (i.e. they will not dispatch work or handle web requests as control nodes do).
-
-Hop nodes can be added to sit between the control plane of AWX and stand alone execution nodes. These machines will not be a part of the AWX Kubernetes cluster. The machines will be registered in AWX as node type "hop", meaning they will only handle inbound / outbound traffic for otherwise unreachable nodes in a different or more strict network. 
-
-Below is an example of an AWX Task pod with two execution nodes. Traffic to execution node 2 flows through a hop node that is setup between it and the control plane.
-
-```
-                                                     AWX TASK POD
-                                                   ┌──────────────┐
-                                                   │              │
-                                                   │ ┌──────────┐ │
-┌─────────────────┐   ┌─────────────────┐          │ │ awx-task │ │
-│execution node 2 ├──►│     hop node    │◄────┐    │ ├──────────┤ │
-└─────────────────┘   ├─────────────────┤     ├────┼─┤ awx-ee   │ │
-                      │ execution node 1│◄────┘    │ └──────────┘ │
-                      └─────────────────┘ Receptor │              | 
-                                            TCP    └──────────────┘
-                                           Peers                 
-                                                   
-```
-
-## Overview
-Adding an execution instance involves a handful of steps:
-
-1. [Start a machine that is accessible from the k8s cluster (Red Hat family of operating systems are supported)](#start-machine)
-2. [Create a new AWX Instance with `hostname` being the IP or DNS name of your remote machine.](#create-instance-in-awx)
-3. [Download the install bundle for this newly created instance.](#download-the-install-bundle)
-4. [Run the install bundle playbook against your remote machine.](#run-the-install-bundle-playbook)
-5. [Wait for the instance to report a Ready state. Now jobs can run on that instance.](#wait-for-instance-to-be-ready)
-
-
-### Start machine
-
-Bring a machine online with a compatible Red Hat family OS (e.g. RHEL 8 and 9). This machines needs a static IP, or a resolvable DNS hostname that the AWX cluster can access. If the listener_port is defined, the machine will also need an available open port to establish inbound TCP connections on (e.g. 27199).
-
-In general the more CPU cores and memory the machine has, the more jobs that can be scheduled to run on that machine at once. See https://docs.ansible.com/automation-controller/4.2.1/html/userguide/jobs.html#at-capacity-determination-and-job-impact for more information on capacity.
-
-
-### Create instance in AWX
-
-Use the Instance page or `api/v2/instances` endpoint to add a new instance.
-- `hostname` ("Name" in UI) is the IP address or DNS name of your machine.
-- `node_type` is "execution" or "hop"
-- `node_state` is "installed"
-- `listener_port` is an open port on the remote machine used to establish inbound TCP connections. Defaults to null.
-- `peers` is a list of instance hostnames to connect outbound to.
-- `peers_from_control_nodes` boolean, if True, control plane nodes will automatically peer to this instance.
-
-Below is a table of configurations for the [diagram](#adding-execution-nodes-to-awx) above.
-
-| instance name    | listener_port | peers_from_control_nodes | peers       |
-|------------------|---------------|-------------------------|--------------|
-| execution node 1 | 27199         | true                    | []           |
-| hop node         | 27199         | true                    | []           |
-| execution node 2 | null          | false                   | ["hop node"] |
-
-Listener port needs to be set if peers_from_control_nodes is enabled or the instance is a peer.
-
-
-### Download the install bundle
-
-On the Instance Details page, click Install Bundle and save the tar.gz file to your local computer and extract contents. Alternatively, make a GET request to `api/v2/instances/{id}/install_bundle` and save the binary output to a tar.gz file.
-
-
-### Run the install bundle playbook
-
-In order for AWX to make proper TCP connections to the remote machine, a few files need to in place. These include TLS certificates and keys, a certificate authority, and a proper Receptor configuration file. To facilitate that these files will be in the right location on the remote machine, the install bundle includes an install_receptor.yml playbook.
-
-The playbook requires the Receptor collection which can be obtained via
-
-`ansible-galaxy collection install -r requirements.yml`
-
-Modify `inventory.yml`. Set the `ansible_user` and any other ansible variables that may be needed to run playbooks against the remote machine.
-
-`ansible-playbook -i inventory.yml install_receptor.yml` to start installing Receptor on the remote machine.
-
-
-### Wait for instance to be Ready
-
-Wait a few minutes for the periodic AWX task to do a health check against the new instance. The instances endpoint or page should report "Ready" status for the instance. If so, jobs are now ready to run on this machine!
-
-
-## Removing instances
-
-You can remove an instance by clicking "Remove" in the Instances page, or by setting the instance `node_state` to "deprovisioning" via the API.
-
-## Troubleshooting
-
-### Fact cache not working
-
-Make sure the system timezone on the execution node matches `settings.TIME_ZONE` (default is 'UTC') on AWX.
-Fact caching relies on comparing modified times of artifact files, and these modified times are not timezone-aware. Therefore, it is critical that the timezones of the execution nodes match AWX's timezone setting.
-
-To set the system timezone to UTC
-
-`ln -s /usr/share/zoneinfo/Etc/UTC /etc/localtime`
-
-### Permission denied errors
-
-Jobs may fail with the following error
-```
-"msg":"exec container process `/usr/local/bin/entrypoint`: Permission denied"
-```
-or similar
-
-For RHEL based machines, this could due to SELinux that is enabled on the system.
-
-You can pass these `extra_settings` container options to override SELinux protections.
-
-`DEFAULT_CONTAINER_RUN_OPTIONS = ['--network', 'slirp4netns:enable_ipv6=true', '--security-opt', 'label=disable']`

docs/rbac.md

@@ -1,173 +1,13 @@
 # Role-Based Access Control (RBAC)
 
-This document describes the RBAC implementation of the AWX Software.
-The intended audience of this document is the AWX developer.
+The Role-Based Access Control system has been moved to the django-ansible-base library.
+
+https://github.com/ansible/django-ansible-base
 
 ## Overview
 
 ### RBAC - System Basics
 
-There are three main concepts to be familiar with: Roles, Resources, and Users.
-Users can be members of a role, which gives them certain access to any
-resources associated with that role, or any resources associated with "descendent"
-roles.
-
-For example, if I have an organization named "MyCompany" and I want to allow
-two people, "Alice", and "Bob", access to manage all of the settings associated
-with that organization, I'd make them both members of the organization's `admin_role`.
-
-It is often the case that you have many Roles in a system, and you want some
-roles to include all of the capabilities of other roles. For example, you may
-want a System Administrator to have access to everything that an Organization
-Administrator has access to, who has everything that a Project Administrator
-has access to, and so on. We refer to this concept as the 'Role Hierarchy', and
-is represented by allowing roles to have "Parent Roles". Any permission that a
-role has is implicitly granted to any parent roles (or parents of those
-parents, and so on). Of course roles can have more than one parent, and
-capabilities are implicitly granted to all parents. (Technically speaking, this
-forms a directional acyclic graph instead of a strict hierarchy, but the
-concept should remain intuitive.)
+Illustrations from the old RBAC system, before the move to django-ansible-base.
 
 ![Example RBAC hierarchy](img/rbac_example.png?raw=true)
-
-
-### Implementation Overview
-
-The RBAC system allows you to create and layer roles for controlling access to resources. Any Django Model can
-be made into a resource in the RBAC system by using the `ResourceMixin`. Once a model is accessible as a resource, you can
-extend the model definition to have specific roles using the `ImplicitRoleField`. Within the declaration of
-this role field you can also specify any parents the role may have, and the RBAC system will take care of
-all of the appropriate ancestral binding that takes place behind the scenes to ensure that the model you've declared
-is kept up to date as the relations in your model change.
-
-### Roles
-
-Roles are defined for a resource. If a role has any parents, these parents will be considered when determining
-what roles are checked when accessing a resource.
-
-    ResourceA
-     |-- AdminRole
-
-    ResourceB
-     | -- AdminRole
-           |-- parent = ResourceA.AdminRole
-
-When a user attempts to access ResourceB, we will check for their access using the set of all unique roles, including the parents.
-
-    ResourceA.AdminRole, ResourceB.AdminRole
-
-This would provide any members of the above roles with access to ResourceB.
-
-#### Singleton Role
-
-There is a special case _Singleton Role_ that you can create. This type of role is for system-wide roles.
-
-### Models
-
-The RBAC system defines a few new models. These models represent the underlying RBAC implementation and generally will be abstracted away from your daily development tasks by the implicit fields and mixins.
-
-#### `Role`
-
-`Role` defines a single role within the RBAC implementation. It encapsulates the `ancestors`, `parents`, and `members` for a role. This model is intentionally kept dumb and it has no explicit knowledge of a `Resource`. The `Role` model (get it?), defines some methods that aid in the granting and creation of roles.
-
-##### `visible_roles(cls, user)`
-
-`visible_roles` is a class method that will look up all of the `Role` instances a user can "see". This includes any roles the user is a direct descendent of as well as any ancestor roles.
-
-##### `singleton(cls, name)`
-
-The `singleton` class method is a helper method on the `Role` model that helps in the creation of singleton roles. It will return the role by name if it already exists or create and return the new role in the case it does not.
-
-##### `get_absolute_url(self)`
-
-`get_absolute_url` returns the consumable URL endpoint for the `Role`.
-
-##### `rebuild_role_ancestor_list(self)`
-
-`rebuild_role_ancestor_list` will rebuild the current role ancestry that is stored in the `ancestors` field of a `Role`. This is called for you by `save` and different Django signals.
-
-##### `is_ancestor_of(self, role)`
-
-`is_ancestor_of` returns if the given `role` is an ancestor of the current `Role` instance.
-
-##### `user in role`
-
-You may use the `user in some_role` syntax to check and see if the specified
-user is a member of the given role, **or** a member of any ancestor role.
-
-#### `get_roles_on_resource(resource, accessor)`
-
-This is a static method (not bound to a class) that will efficiently return the names
-of all roles that the `accessor` (a user or a team) has on a particular resource.
-The resource is a python object for something like an organization, credential, or job template.
-Return value is a list of strings like `["admin_role", "execute_role"]`.
-
-### Fields
-
-#### `ImplicitRoleField`
-
-`ImplicitRoleField` fields are declared on your model. They provide the definition of grantable roles for accessing your resource. You may (and should) use the `parent_role` parameter to specify any parent roles that should inherit privileges implied by the role.
-
-`parent_role` is the link to any parent roles you want considered when a user
-is requesting access to your resource. A `parent_role` can be declared as a
-single string, `"parent.read_role"`, or a list of many roles,
-`['parentA.read_role', 'parentB.read_role']` which will make each listed role a parent. You can also use the syntax
-`[('parentA.read_role', 'parentB.read_role'), 'parentC.read_role']` to make
-`(parentA.read_role OR parentB.read_role) AND 'parentC.read_role` parents (so `parentB.read_role` will be added only if `parentA.read_role` was `None`).
-If any listed role can't be evaluated (for example if there are `None` components in the path), then they are simply ignored until the value of the field changes.
-
-
-### Mixins
-
-#### `ResourceMixin`
-
-By mixing in the `ResourceMixin` to your model, you are turning your model in to a resource in the eyes of the RBAC implementation. Your model will gain the helper methods that aid in the checking the access a users roles provides them to your resource.
-
-##### `accessible_objects(cls, user, role_field)`
-
-`accessible_objects` is a class method to use instead of `Model.objects`. This method will restrict the query of objects to only those that the user has access to - specifically those objects which the user is a member of the specified role (either directly or indirectly).
-
-```python
-    objects = MyModel.accessible_objects(user, 'admin_role')
-    objects.filter(name__istartswith='december')
-```
-
-##### `accessible_pk_qs(cls, user, role_field)`
-
-`accessible_pk_qs` returns a queryset of ids that match the same role filter as `accessible_objects`.
-A key difference is that this is more performant to use in subqueries when filtering related models.
-
-Say that another model, `YourModel` has a ForeignKey reference to `MyModel` via a field `my_model`,
-and you want to return all instances of `YourModel` that have a visible related `MyModel`.
-The best way to do this is:
-
-```python
-    YourModel.filter(my_model=MyModel.accessible_pk_qs(user, 'admin_role'))
-```
-
-## Usage
-
-After exploring the _Overview_, the usage of the RBAC implementation in your code should feel unobtrusive and natural.
-
-```python
-    # make your model a Resource
-    class Document(Model, ResourceMixin):
-       ...
-    # declare your new role
-    readonly_role = ImplicitRoleField()
-```
-
-Now that your model is a resource and has a `Role` defined, you can begin to access the helper methods provided to you by the `ResourceMixin` for checking a user's access to your resource. Here is the output of a Python REPL session:
-
-```python
-    # we've created some documents and a user
-    >>> document = Document.objects.filter(pk=1)
-    >>> user = User.objects.first()
-    >>> user in document.readonly_role
-    False  # not accessible by default
-    >>> document.readonly_role.members.add(user)
-    >>> user in document.readonly_role
-    True   # now it is accessible
-    >>> user in document.readonly_role
-    False  # my role does not have admin permission
-```

docs/release_process.md

@@ -124,10 +124,14 @@ This workflow will take the generated images and promote them to quay.io in addi
 
 ![Verify release awx.awx collection](img/galaxy.png)
 
-8. Go to awxkit's page on [PiPy](https://pypi.org/project/awxkit/#history) and validate the latest release is there:
+8. Go to awxkit's page on [PyPi](https://pypi.org/project/awxkit/#history) and validate the latest release is there:
 
 ![Verify awxkit](img/pypi.png)
 
+9. While verifying that awxkit was published on Pypi, also validate that the latest version of the [tar](https://pypi.org/project/awxkit/#files) file is there as well.
+
+![Verify awxkit files](img/pypi_files.png)
+
 ### Releasing the AWX operator
 
 Once the AWX image is live, we can now release the AWX operator.
@@ -145,15 +149,32 @@ This workflow will take the generated images and promote them to quay.io.
 ![Verify released awx-operator image](img/verify-released-awx-operator-image.png)
 
 ## Send notifications
+
 Send notifications to the following groups:
-  * AWX Mailing List
-  * #social:ansible.com IRC (@newsbot for inclusion in bullhorn)
-  * #awx:ansible.com (no @newsbot in this room)
-  * #ansible-controller slack channel
+
+  * [Ansible Community forum](https://forum.ansible.com/)
+  * [#social:ansible.com](https://matrix.to/#/#social:ansible.com) `@newsbot` for inclusion in The Bullhorn)
+  * [#awx:ansible.com](https://forum.ansible.com/g/AWX/members)
+  * #aap-controller Slack channel
 
 These messages are templated out for you in the output of `get_next_release.yml`.
 
-Note: the slack message is the same as the IRC message.
+Note: The Slack message is the same as the Matrix message.
+
+### Announcements
+
+* Provide enough information for the reader
+* Include:
+  * **What:** What is this, why should someone care
+  * **Why:** Why is this important
+  * **How:** How do I use this (docs, config options)
+  * **Call to action:** What type of feedback are we looking for
+* Link to PR(s) for larger features
+* `@newsbot` supports [Markdown](https://www.markdownguide.org/cheat-sheet/), so use formatted links, bullet points
+* Release Manager posts into social Matrix Channel
+* Appears in next weeks [Bulhorn](https://forum.ansible.com/c/news/bullhorn)
+
+
 
 ## Create operator hub PRs.
 Operator hub PRs are generated via an Ansible Playbook. See someone on the AWX team for the location of the playbooks and instructions on how to run them.