Create AWX docsite with RST content (#14328)

Co-authored-by: Thanhnguyet Vo <tvo@ansible.com>
Co-authored-by: TVo <thavo@redhat.com>

docs/docsite/rst/upgrade_migration/index.rst

@@ -0,0 +1,15 @@
+.. _upgrade_migration_start:
+
+=======================================
+Upgrading and Migrating AWX Deployments
+=======================================
+
+Upgrading and Migrating AWX Deployments
+
+.. toctree::
+   :maxdepth: 2
+   :numbered:
+
+   self
+   upgrade_considerations
+   upgrade_to_ees

docs/docsite/rst/upgrade_migration/upgrade_considerations.rst

@@ -0,0 +1,29 @@
+
+
+Upgrading AWX 
+==============
+
+.. index::
+    single: upgrade considerations
+    single: upgrade
+
+Refer to :ref:`ag_restart_awx` for detail.
+
+.. contents::
+    :local:
+
+.. _upgrade_planning:
+
+Upgrade Planning
+------------------
+
+This section covers changes that you should keep in mind as you attempt to upgrade your AWX instance.
+
+- Clustered upgrades require special attention to instance and instance groups prior to starting the upgrade. See `:ref:`ag_clustering` for details.
+
+
+Running the Setup Playbook
+----------------------------
+
+.. include:: ../common/setup-playbook.rst    
+

docs/docsite/rst/upgrade_migration/upgrade_to_ees.rst

@@ -0,0 +1,37 @@
+.. _upgrade_venv:
+
+Upgrading to Execution Environments
+===================================
+
+.. index::
+    single: execution environment
+    pair: Ansible; executing in a execution environment
+    pair: build; execution environments
+
+Refer to :ref:`ag_restart_awx` in the |ata| and :ref:`ug_execution_environments` in the |atu| for detail.
+
+
+.. Important::
+
+    When upgrading, it is highly recommended to always rebuild on top of the base |ee| that corresponds to the AWX version you are using. See :ref:`ug_build_ees` for more information.
+
+
+.. _mesh_topology_ee:
+
+View mesh topology
+------------------
+.. index::
+   single: mesh
+   pair: mesh; graph
+   pair: execution environments; mesh
+
+
+If you configured a :term:`mesh` topology, the installer can graphically validate your mesh configuration through a generated graph rendering tool. The graph is generated by reading the contents of the inventory file.
+
+.. image:: ../common/images/mesh-topology-rendering.png
+
+Any given inventory file must include some sort of execution capacity that is governed by at least one control :term:`node`. That is, it is unacceptable to produce an inventory file that only contains control-only nodes, execution-only nodes or hop-only nodes. There is a tightly coupled relationship between control and execution nodes that must be respected at all times. The installer will fail if the inventory files aren't properly defined. The only exception to this rule would be a single hybrid node, as it will satisfy the control and execution constraints.
+
+In order to run jobs on an execution node, either the installer needs to pre-register the node, or user needs to make a PATCH request to ``/api/v2/instances/N/`` to change the enabled field to true.
+
+If you have already deployed a mesh topology and want to view node type, node health, and specific details about each node, see :ref:`ag_topology_viewer` in the |ata|.