diff --git a/doc/requirements.txt b/doc/requirements.txt
new file mode 100644
index 0000000..8c261cd
--- /dev/null
+++ b/doc/requirements.txt
@@ -0,0 +1,5 @@
+dunamai
+furo
+sphinx
+sphinx-autobuild
+sphinx-copybutton
diff --git a/doc/source/_static/.gitkeep b/doc/source/_static/.gitkeep
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/doc/source/_static/.gitkeep
diff --git a/doc/source/admin/images/monitoring-alertmanger-list.png b/doc/source/admin/images/monitoring-alertmanger-list.png
new file mode 100644
index 0000000..3b6e08b
--- /dev/null
+++ b/doc/source/admin/images/monitoring-alertmanger-list.png
Binary files differ
diff --git a/doc/source/admin/images/monitoring-silences-menu.png b/doc/source/admin/images/monitoring-silences-menu.png
new file mode 100644
index 0000000..a793bb1
--- /dev/null
+++ b/doc/source/admin/images/monitoring-silences-menu.png
Binary files differ
diff --git a/doc/source/admin/index.rst b/doc/source/admin/index.rst
new file mode 100644
index 0000000..87d5546
--- /dev/null
+++ b/doc/source/admin/index.rst
@@ -0,0 +1,19 @@
+Administrator Documentation
+===========================
+
+This section is designed to equip system administrators with the knowledge and
+tools necessary for the effective management and operation of the Atmosphere
+deployment. It offers comprehensive guides and resources across various aspects
+of system administration, including troubleshooting, maintenance, and more.
+
+Intended for administrators tasked with the setup and ongoing management of
+Atmosphere, this documentation aims to provide clear and practical
+information to ensure stable and efficient operation of the system.
+
+.. toctree::
+   :maxdepth: 2
+
+   integration
+   monitoring
+   maintenance
+   troubleshooting
diff --git a/doc/source/admin/integration.rst b/doc/source/admin/integration.rst
new file mode 100644
index 0000000..7350c61
--- /dev/null
+++ b/doc/source/admin/integration.rst
@@ -0,0 +1,77 @@
+#################
+Integration Guide
+#################
+
+This section provides detailed instructions on integrating external systems
+and services with Atmosphere, enhancing functionality and streamlining workflows.
+
+********
+Keycloak
+********
+
+Keycloak serves as a comprehensive identity and access management solution,
+facilitating the integration of various identity providers for centralized user
+authentication and authorization. By leveraging federated identity, Keycloak enables
+seamless Single Sign-On (SSO) capabilities across a suite of applications, enhancing
+the user experience and bolstering security measures.
+
+Identity Providers
+==================
+
+Incorporating identity providers into Keycloak allows users to authenticate via trusted
+external sources. This federated authentication scheme simplifies the login process by
+using existing credentials, whether from enterprise directories like LDAP or other
+identity services.
+
+Azure AD
+--------
+
+Azure AD is recognized for its extensive adoption and integration within the enterprise
+ecosystem, offers a secure and familiar authentication method for countless users.
+
+You can begin the integration process by creating an application registration in Azure AD
+and configuring the necessary settings in Keycloak. The following steps outline the
+procedure:
+
+1. Sign in to the Azure portal and access the **Azure Active Directory** service.
+2. Navigate to **App registrations** and click **New registration**.
+3. Fill in the application name, select the account types it will serve, and
+   specify a **Redirect URI**.
+
+At this point, you'll need to grab the **Redirect URI** from the Keycloak client settings
+using the following steps:
+
+1. Log into the Keycloak admin console using your administrator credentials.
+2. Switch to the ``atmosphere`` realm where you'll be configuring Azure AD.
+3. In the **Identity Providers** section, select **Add provider** and choose **Microsoft**.
+4. Keycloak will generate a **Redirect URI** which you will use in the Azure AD
+   application registration process to ensure that authentication responses are
+   correctly routed.
+
+At this point, you'll be able to finalize the Azure AD application registration by
+following these remaining steps:
+
+1. Return to the Azure AD application registration page and input the Redirect
+   URI from Keycloak.
+2. After the application is registered, navigate to **Certificates & secrets**
+   to create a client secret.
+3. Record the **Client ID** and **Client Secret** provided, as they will be
+   needed to configure Keycloak.
+
+At this point, you're ready to configure Keycloak with the Azure AD settings:
+
+1. In the Keycloak admin console, navigate back to the `atmosphere` realm's
+   **Identity Providers** section.
+2. For the Microsoft provider configuration, enter the **Client ID** and
+   **Client Secret** obtained from Azure AD.
+3. Adjust any additional settings according to your requirements, such as the
+   default scopes, mappers, and other provider-specific configurations.
+4. Save your changes to finalize the integration.
+
+By integrating Azure AD with Keycloak, you enable users to authenticate with
+their corporate credentials across all applications that are secured by
+Keycloak. This provides a consistent and secure user experience, leveraging
+the robust features of Azure AD within the flexible framework of Keycloak.
+
+For a deeper dive into the Azure AD configuration within Keycloak, consult the
+`Keycloak Microsoft Identity Provider documentation <https://www.keycloak.org/docs/latest/server_admin/#_microsoft>`_.
diff --git a/doc/source/admin/maintenance.rst b/doc/source/admin/maintenance.rst
new file mode 100644
index 0000000..362b152
--- /dev/null
+++ b/doc/source/admin/maintenance.rst
@@ -0,0 +1,31 @@
+#################
+Maintenance Guide
+#################
+
+This guide provides instructions for regular maintenance tasks necessary to
+ensure the smooth and secure operation of the system.
+
+*********************
+Renewing Certificates
+*********************
+
+The certificates used by the Kubernetes cluster are valid for one year.  They
+are automatically renewed when the cluster is upgraded to a new version of
+Kubernetes.  However, if you are running the same version of Kubernetes for
+more than a year, you will need to manually renew the certificates.
+
+To renew the certificates, run the following command on each one of your
+control plane nodes:
+
+.. code-block:: console
+
+    $ sudo kubeadm certs renew all
+
+Once the certificates have been renewed, you will need to restart the
+Kubernetes control plane components to pick up the new certificates.  You need
+to do this on each one of your control plane nodes by running the following
+command one at a time on each node:
+
+.. code-block:: console
+
+    $ ps auxf | egrep '(kube-(apiserver|controller-manager|scheduler)|etcd)' | awk '{ print $2 }' | xargs sudo kill
diff --git a/doc/source/admin/monitoring.rst b/doc/source/admin/monitoring.rst
new file mode 100644
index 0000000..d196e15
--- /dev/null
+++ b/doc/source/admin/monitoring.rst
@@ -0,0 +1,463 @@
+#########################
+Monitoring and Operations
+#########################
+
+There is a Grafana deployment with a few dashboards that are created by default
+and a Prometheus deployment that is used to collect metrics from the cluster
+which sends alerts to AlertManager. In addition, Loki is deployed to collect
+logs from the cluster using Vector.
+
+******************************
+Philosophy and Alerting Levels
+******************************
+
+Atmosphere's monitoring philosophy is strongly aligned with the principles
+outlined in the Google Site Reliability Engineering (SRE) book. Our approach
+focuses on alerting on conditions that are symptomatic of issues which directly
+impact the service or system health, rather than simply monitoring the state of
+individual components.
+
+Alerting Philosophy
+===================
+
+Our alerting philosophy aims to alert the right people at the right time. Most
+alerts, if they are affecting a single system, would trigger a lower priority
+level (P4 or P5). However, if an issue is affecting the entire control plane of
+a specific service, it might escalate to a P3 or P2. And if the whole service
+is unavailable, it becomes a P1.
+
+We believe in minimizing alert noise to ensure that alerts are meaningful and
+actionable. Our goal is to have every alert provide enough information to
+initiate an immediate and effective response, regardless of business hours for
+high priority alerts.
+
+We continue to refine our monitoring and alerting strategies to ensure that we
+are effectively identifying and responding to incidents. The ultimate goal is
+to provide a reliable and high-quality service to all our users.
+
+Severity Levels
+===============
+
+Our alerting system classifies incidents into different severity levels based on
+their impact on the system and users.
+
+**P1**: Critical
+  This level is used for incidents causing a complete service disruption or
+  significant loss of functionality across the entire Atmosphere platform.
+  Immediate response, attention, and action are necessary regardless of
+  business hours.
+
+**P2**: High
+  This level is for incidents that affect a large group of users or critical
+  system components. These incidents require swift attention and action,
+  regardless of business hours, but do not cause a total disruption.
+
+**P3**: Moderate
+  This level is for incidents that affect a smaller group of users or a single
+  system. These incidents require attention and may necessitate action during
+  business hours.
+
+**P4**: Low
+  This level is used for minor issues that have a limited impact on a small
+  subset of users or system functionality. These incidents require attention
+  and action, if necessary, during standard business hours.
+
+**P5**: Informational
+  This is the lowest level of severity, used for providing information about
+  normal system activities or minor issues that don't significantly impact
+  users or system functionality. These incidents typically do not require
+  immediate attention or action and are addressed during standard business
+  hours.
+
+**********************
+Operational Procedures
+**********************
+
+Creating silences
+=================
+
+In order to create a silence, you'll need to login to your Grafana instance that
+is deployed as part of Atmosphere as an admin user.
+
+1. Click on the hamburger menu in the top left corner and select "Alerting"
+   and then "Silences" from the menu.
+
+   .. image:: images/monitoring-silences-menu.png
+      :alt: Silences menu
+      :width: 200
+
+2. Ensure that you select "AlertManager" on the top right corner of the page,
+   this will make sure that you create a silence inside of the AlertManager
+   that is managed by the Prometheus operator instead of the built-in Grafana
+   AlertManager which is not used.
+
+    .. image:: images/monitoring-alertmanger-list.png
+        :alt: AlertManager list
+        :width: 200
+
+   .. admonition:: AlertManager selection
+    :class: warning
+
+    It's important that you select the AlertManager that is managed by the
+    Prometheus operator, otherwise your silence will not be applied to the
+    Prometheus instance that is deployed as part of Atmosphere.
+
+3. Click the "Add Silence" button and use the AlertManager format to create
+   your silence, which you can test by seeing if it matches any alerts in the
+   list labeled "Affected alert instances".
+
+.. admonition:: Limit the number of labels
+    :class: info
+
+    It is important to limit the number of labels that you use in your silence
+    to ensure that it will continue to work even if the alerts are modified.
+
+    For example, if you have an alert that is labeled with the following labels:
+
+    - ``alertname``
+    - ``instance``
+    - ``job``
+    - ``severity``
+
+    You should only use the ``alertname`` and ``severity`` labels in your
+    silence to ensure that it will continue to work even if the ``instance``
+    or ``job`` labels are modified.
+
+**************
+Configurations
+**************
+
+Dashboard Management
+====================
+
+For Grafana, rather than enabling persistence through the application's user
+interface or manual Helm chart modifications, dashboards should be managed
+directly via the Helm chart values.
+
+.. admonition:: Avoid Manual Persistence Configurations!
+    :class: warning
+
+    It is important to avoid manual persistence configurations, especially for
+    services like Grafana, where dashboards and data sources can be saved. Such
+    practices are not captured in version control and pose a risk of data loss,
+    configuration drift, and upgrade complications.
+
+To manage Grafana dashboards through Helm, you can include the dashboard
+definitions within your configuration file. By doing so, you facilitate
+version-controlled dashboard configurations that can be replicated across
+different deployments without manual intervention.
+
+For example, a dashboard can be defined in the Helm values like this:
+
+.. code-block:: yaml
+
+  kube_prometheus_stack_helm_values:
+    grafana:
+      dashboards:
+        default:
+          my-dashboard:
+            gnetId: 10000
+            revision: 1
+            datasource: Prometheus
+
+This instructs Helm to fetch and configure the specified dashboard from
+`Grafana.com dashboards <https://grafana.com/grafana/dashboards/>`_, using
+Prometheus as the data source.  You can find more examples of how to do
+this in the Grafana Helm chart `Import Dashboards <https://github.com/grafana/helm-charts/tree/main/charts/grafana#import-dashboards>`_
+documentation.
+
+************
+Viewing data
+************
+
+There are a few different ways to view the data that is collected by the
+monitoring stack.  The most common ways are through AlertManager, Grafana, and
+Prometheus.
+
+Grafana dashboard
+=================
+
+By default, an ``Ingress`` is created for Grafana using the
+``kube_prometheus_stack_grafana_host`` variable.  The authentication is done
+using the Keycloak service which is deployed by default.
+
+Inside Keycloak, there are two client roles that are created for Grafana:
+
+``grafana:admin``
+  Has access to all organization resources, including dashboards, users, and
+  teams.
+
+``grafana:editor``
+  Can view and edit dashboards, folders, and playlists.
+
+``grafana:viewer``
+  Can view dashboards, playlists, and query data sources.
+
+You can view the existing dashboards by going to *Manage* > *Dashboards*. You
+can also check any alerts that are currently firing by going to *Alerting* >
+*Alerts*.
+
+Prometheus
+==========
+
+By default, Prometheus is exposed behind an ``Ingress`` using the
+``kube_prometheus_stack_prometheus_host`` variable.  In addition, it is also
+running behind the `oauth2-proxy` service which is used for authentication
+so that only authenticated users can access the Prometheus UI.
+
+Alternative Authentication
+--------------------------
+
+It is possible to by-pass the `oauth2-proxy` service and use an alternative
+authentication method to access the Prometheus UI.  In both cases, we will
+be overriding the ``servicePort`` on the ``Ingress`` to point to the port
+where Prometheus is running and not the `oauth2-proxy` service.
+
+.. admonition:: Advanced Usage Only
+    :class: warning
+
+    It's strongly recommended that you stick to keeping the `oauth2-proxy`
+    service in front of the Prometheus UI.  The `oauth2-proxy` service is
+    responsible for authenticating users and ensuring that only authenticated
+    users can access the Prometheus UI.
+
+Basic Authentication
+~~~~~~~~~~~~~~~~~~~~
+
+If you want to rely on basic authentication to access the Prometheus UI instead
+of using the `oauth2-proxy` service to expose it over single sign-on, you can
+do so by making the following changes to your inventory:
+
+.. code-block:: yaml
+
+  kube_prometheus_stack_helm_values:
+    prometheus:
+      ingress:
+        servicePort: 8080
+        annotations:
+          nginx.ingress.kubernetes.io/auth-type: basic
+          nginx.ingress.kubernetes.io/auth-secret: basic-auth-secret-name
+
+In the example above, we are using the ``basic-auth-secret-name`` secret to
+authenticate users.  The secret should be created in the same namespace as the
+Prometheus deployment based on the `Ingress NGINX Annotations <https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md#annotations>`_.
+
+IP Whitelisting
+~~~~~~~~~~~~~~~
+
+If you want to whitelist specific IPs to access the Prometheus UI, you can do
+so by making the following changes to your inventory:
+
+.. code-block:: yaml
+
+  kube_prometheus_stack_helm_values:
+    prometheus:
+      ingress:
+        servicePort: 8080
+        annotations:
+          nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/24,172.10.0.1"
+
+In the example above, we are whitelisting the IP range ``10.0.0.0/24`` and the IP address
+``172.10.0.1``.
+
+AlertManager
+============
+
+By default, the AlertManager dashboard is pointing to the Ansible variable
+``kube_prometheus_stack_alertmanager_host`` and is exposed using an ``Ingress``
+behind the `oauth2-proxy` service, protected by Keycloak similar to Prometheus.
+
+************
+Integrations
+************
+
+Since Atmosphere relies on AlertManager to send alerts, it is possible to
+integrate it with services like OpsGenie, PagerDuty, email and more.  To
+receive monitoring alerts using your preferred notification tools, you'll
+need to integrate them with AlertManager.
+
+OpsGenie
+========
+
+In order to get started, you will need to complete the following steps inside
+OpsGenie:
+
+1. Create an integration inside OpsGenie, you can do this by going to
+   *Settings* > *Integrations* > *Add Integration* and selecting *Prometheus*.
+2. Copy the API key that is generated for you and setup correct assignment
+   rules inside OpsGenie.
+3. Create a new heartbeat inside OpsGenie, you can do this by going to
+   *Settings* > *Heartbeats* > *Create Heartbeat*. Set the interval to 1 minute.
+
+Afterwards, you can configure the following options for the Atmosphere config,
+making sure that you replace the placeholders with the correct values:
+
+``API_KEY``
+  The API key that you copied from the OpsGenie integration.
+
+``HEARTBEAT_NAME``
+  The name of the heartbeat that you created inside OpsGenie
+
+.. code-block:: yaml
+
+  kube_prometheus_stack_helm_values:
+    alertmanager:
+      config:
+        receivers:
+          - name: "null"
+          - name: notifier
+            opsgenie_configs:
+              - api_key: API_KEY
+                message: >-
+                  {% raw -%}
+                  {{ .GroupLabels.alertname }}
+                  {%- endraw %}
+                priority: >-
+                  {% raw -%}
+                  {{- if eq .GroupLabels.severity "critical" -}}
+                  P1
+                  {{- else if eq .GroupLabels.severity "warning" -}}
+                  P3
+                  {{- else if eq .GroupLabels.severity "info" -}}
+                  P5
+                  {{- else -}}
+                  {{ .GroupLabels.severity }}
+                  {{- end -}}
+                  {%- endraw %}
+                description: |-
+                  {% raw -%}
+                  {{ if gt (len .Alerts.Firing) 0 -}}
+                  Alerts Firing:
+                  {{ range .Alerts.Firing }}
+                    - Message: {{ .Annotations.message }}
+                      Labels:
+                  {{ range .Labels.SortedPairs }}   - {{ .Name }} = {{ .Value }}
+                  {{ end }}   Annotations:
+                  {{ range .Annotations.SortedPairs }}   - {{ .Name }} = {{ .Value }}
+                  {{ end }}   Source: {{ .GeneratorURL }}
+                  {{ end }}
+                  {{- end }}
+                  {{ if gt (len .Alerts.Resolved) 0 -}}
+                  Alerts Resolved:
+                  {{ range .Alerts.Resolved }}
+                    - Message: {{ .Annotations.message }}
+                      Labels:
+                  {{ range .Labels.SortedPairs }}   - {{ .Name }} = {{ .Value }}
+                  {{ end }}   Annotations:
+                  {{ range .Annotations.SortedPairs }}   - {{ .Name }} = {{ .Value }}
+                  {{ end }}   Source: {{ .GeneratorURL }}
+                  {{ end }}
+                  {{- end }}
+                  {%- endraw %}
+          - name: heartbeat
+            webhook_configs:
+              - url: https://api.opsgenie.com/v2/heartbeats/HEARTBEAT_NAME/ping
+                send_resolved: false
+                http_config:
+                  basic_auth:
+                    password: API_KEY
+
+Once this is done and deployed, you'll start to see alerts inside OpsGenie and
+you can also verify that the heartbeat is listed as *ACTIVE*.
+
+PagerDuty
+=========
+
+To integrate with Pagerduty, first you need to prepare an *Integration key*. In
+order to do that, you must decide how you want to integrate with PagerDuty since
+there are two ways to do it:
+
+**Event Orchestration**
+  This method is beneficial if you want to build different routing rules based
+  on the events coming from the integrated tool.
+
+**PagerDuty Service Integration**
+  This method is beneficial if you don't need to route alerts from the integrated
+  tool to different responders based on the event payload.
+
+For both of these methods, you need to create an *Integration key* in PagerDuty
+using the `PagerDuty Integration Guide <https://www.pagerduty.com/docs/guides/prometheus-integration-guide/>`_.
+
+Once you're done, you'll need to configure the inventory with the following
+options:
+
+.. code-block:: yaml
+
+  kube_prometheus_stack_helm_values:
+    alertmanager:
+      config:
+        receivers:
+          - name: notifier
+            pagerduty_configs:
+              - service_key: '<your integration key here>'
+
+You can find more details about
+`pagerduty_configs <https://prometheus.io/docs/alerting/latest/configuration/#pagerduty_config>`_
+in the Prometheus documentation.
+
+Email
+=====
+
+To integrate with email, you need to configure the following options in the
+inventory:
+
+.. code-block:: yaml
+
+  kube_prometheus_stack_helm_values:
+    alertmanager:
+      config:
+        receivers:
+          - name: notifier
+            email_configs:
+              - smarthost: 'smtp.gmail.com:587'
+                auth_username: '<your email id here>'
+                auth_password: '<your email password here>'
+                from: '<your email id here>'
+                to: '<receiver's email id here>'
+                headers:
+                  subject: 'Prometheus Mail Alerts'
+
+You can find more details about
+`email_configs <https://prometheus.io/docs/alerting/latest/configuration/#email_configs>`_
+in the Prometheus documentation.
+
+****************
+Alerts Reference
+****************
+
+``etcdDatabaseHighFragmentationRatio``
+  This alert is triggered when the etcd database has a high fragmentation ratio
+  which can cause performance issues on the cluster.  In order to resolve this
+  issue, you can use the following command:
+
+  .. code-block:: console
+
+    kubectl -n kube-system exec svc/kube-prometheus-stack-kube-etcd -- \
+      etcdctl defrag \
+      --cluster \
+      --cacert /etc/kubernetes/pki/etcd/ca.crt \
+      --key /etc/kubernetes/pki/etcd/server.key \
+      --cert /etc/kubernetes/pki/etcd/server.crt
+
+``NodeNetworkMulticast``
+  This alert is triggered when a node is receiving large volumes of multicast
+  traffic which can be a sign of a misconfigured network or a malicious actor.
+
+  This can result in high CPU usage on the node and can cause the node to become
+  unresponsive. Also, it can be the cause of a very high amount of software
+  interrupts on the node.
+
+  In order to find the root cause of this issue, you can use the following
+  commands:
+
+  .. code-block:: console
+
+    iftop -ni $DEV -f 'multicast and not broadcast'
+
+  With the command above, you're able to see which IP addresses are sending the
+  multicast traffic. Once you have the IP address, you can use the following
+  command to find the server behind it:
+
+  .. code-block:: console
+
+    openstack server list --all-projects --long -n --ip $IP
diff --git a/doc/source/admin/troubleshooting.rst b/doc/source/admin/troubleshooting.rst
new file mode 100644
index 0000000..49f247a
--- /dev/null
+++ b/doc/source/admin/troubleshooting.rst
@@ -0,0 +1,155 @@
+#####################
+Troubleshooting Guide
+#####################
+
+This document aims to provide solutions to common issues encountered during the deployment and operation of Atmosphere. The guide is organized by component and issue type to help you quickly find the most relevant information.
+
+**************************
+Open Virtual Network (OVN)
+**************************
+
+Recovering clusters
+===================
+
+If any of the OVN database pods fail, they will no longer be ready.  You can
+recover the cluster by deleting the pods and allowing them to be recreated.
+
+For example, if the ``ovn-ovsdb-nb-0`` pod fails, you can recover the cluster by
+deleting the pod:
+
+.. code-block:: console
+
+    $ kubectl -n openstack delete pods/ovn-ovsdb-nb-0
+
+If the entire cluster fails, you can recover the cluster by deleting all of the
+pods.  For example, if the southbound database fails, you can recover the
+cluster with this command:
+
+.. code-block:: console
+
+    $ kubectl -n openstack delete pods -lcomponent=ovn-ovsdb-sb
+
+If the state of Neutron is lost from the cluster, you can recover it by running
+the repair command:
+
+.. code-block:: console
+
+    $ kubectl -n openstack exec deploy/neutron-server -- \
+      neutron-ovn-db-sync-util \
+        --debug \
+        --config-file /etc/neutron/neutron.conf \
+        --config-file /tmp/pod-shared/ovn.ini \
+        --config-file /etc/neutron/plugins/ml2/ml2_conf.ini \
+        --ovn-neutron_sync_mode repair
+
+**********************
+Compute Service (Nova)
+**********************
+
+Provisioning Failure Due to ``downloading`` Volume
+==================================================
+
+If you're trying to provision a new instance that is using a volume where the
+backend needs to download images directly from Glance (such as PowerStore for
+example) and it fails with the following error:
+
+.. code-block:: text
+
+    Build of instance 54a41735-a4cb-4312-b812-52e4f3d8c500 aborted: Volume 728bdc40-fc22-4b65-b6b6-c94ee7f98ff0 did not finish being created even after we waited 187 seconds or 61 attempts. And its status is downloading.
+
+This means that the volume service could not download the image before the
+compute service timed out.  Out of the box, Atmosphere ships with the volume
+cache enabled to help offset this issue.  However, if you're using a backend
+that does not support the volume cache, you can increase the timeout by setting
+the following in your ``inventory/group_vars/all/nova.yml`` file:
+
+.. code-block:: yaml
+
+    nova_helm_values:
+      conf:
+        enable_iscsi: true
+        nova:
+          DEFAULT:
+            block_device_allocate_retries: 300
+
+*******************************
+Load Balancer Service (Octavia)
+*******************************
+
+Accessing Amphorae
+==================
+
+Atmosphere configures an SSH keypair which allows you to login to the Amphorae
+for debugging purposes.  The ``octavia-worker`` containers are fully configured
+to allow you to SSH to the Amphorae.
+
+If you have an Amphora running with the IP address ``172.24.0.148``, you can login
+to it by simply executing the following:
+
+.. code-block:: console
+
+    $ kubectl -n openstack exec -it deploy/octavia-worker -- ssh 172.24.0.148
+
+
+Listener with ``provisioning_status`` stuck in ``ERROR``
+========================================================
+
+There are scenarios where the load balancer could be in an ``ACTIVE`` state however
+the listener can be stuck in a ``provisioning_status`` of ``ERROR``.  This is usually
+related to an expired TLS certificate not cleanly recovering.
+
+Another symptom of this issue will be that you'll see the following inside the
+``octavia-worker`` logs:
+
+.. code-block:: text
+
+    ERROR oslo_messaging.rpc.server [None req-ad303faf-7a53-4c55-94a5-28cd61c46619 - e83856ceda5c42df8810df42fef8fc1c - - - -] Exception during message handling: octavia.amphorae.drivers.haproxy.exceptions.InternalServerError: Internal Server Erro
+    ERROR oslo_messaging.rpc.server Traceback (most recent call last):
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/oslo_messaging/rpc/server.py", line 165, in _process_incoming
+    ERROR oslo_messaging.rpc.server     res = self.dispatcher.dispatch(message)
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/oslo_messaging/rpc/dispatcher.py", line 309, in dispatch
+    ERROR oslo_messaging.rpc.server     return self._do_dispatch(endpoint, method, ctxt, args)
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/oslo_messaging/rpc/dispatcher.py", line 229, in _do_dispatch
+    ERROR oslo_messaging.rpc.server     result = func(ctxt, **new_args)
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/octavia/controller/queue/v2/endpoints.py", line 90, in update_pool
+    ERROR oslo_messaging.rpc.server     self.worker.update_pool(original_pool, pool_updates)
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/octavia/controller/worker/v2/controller_worker.py", line 733, in update_pool
+    ERROR oslo_messaging.rpc.server     self.run_flow(
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/octavia/controller/worker/v2/controller_worker.py", line 113, in run_flow
+    ERROR oslo_messaging.rpc.server     tf.run()
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/taskflow/engines/action_engine/engine.py", line 247, in run
+    ERROR oslo_messaging.rpc.server     for _state in self.run_iter(timeout=timeout):
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/taskflow/engines/action_engine/engine.py", line 340, in run_iter
+    ERROR oslo_messaging.rpc.server     failure.Failure.reraise_if_any(er_failures)
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/taskflow/types/failure.py", line 338, in reraise_if_any
+    ERROR oslo_messaging.rpc.server     failures[0].reraise()
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/taskflow/types/failure.py", line 350, in reraise
+    ERROR oslo_messaging.rpc.server     raise value
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/taskflow/engines/action_engine/executor.py", line 52, in _execute_task
+    ERROR oslo_messaging.rpc.server     result = task.execute(**arguments)
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/octavia/controller/worker/v2/tasks/amphora_driver_tasks.py", line 157, in execute
+    ERROR oslo_messaging.rpc.server     self.amphora_driver.update(loadbalancer)
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 236, in update
+    ERROR oslo_messaging.rpc.server     self.update_amphora_listeners(loadbalancer, amphora)
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 205, in update_amphora_listeners
+    ERROR oslo_messaging.rpc.server     self.clients[amphora.api_version].upload_config(
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 758, in upload_config
+    ERROR oslo_messaging.rpc.server     return exc.check_exception(r)
+    ERROR oslo_messaging.rpc.server   File "/var/lib/openstack/lib/python3.10/site-packages/octavia/amphorae/drivers/haproxy/exceptions.py", line 44, in check_exception
+    ERROR oslo_messaging.rpc.server     raise responses[status_code]()
+    ERROR oslo_messaging.rpc.server octavia.amphorae.drivers.haproxy.exceptions.InternalServerError: Internal Server Error
+
+You can simply trigger a complete failover of the load balancer which will solve
+the issue:
+
+.. code-block:: console
+
+    $ openstack loadbalancer failover ${LOAD_BALANCER_ID}
+
+.. admonition:: Help us improve Atmosphere!
+    :class: info
+
+    We're trying to collect data with when these failures occur to better understand
+    the root cause.  If you encounter this issue, please reach out to the Atmosphere
+    team so we can better understand the issue by filing an issue with the output of
+    the ``amphora-agent`` logs from the Amphora.
diff --git a/doc/source/conf.py b/doc/source/conf.py
new file mode 100644
index 0000000..f99817d
--- /dev/null
+++ b/doc/source/conf.py
@@ -0,0 +1,35 @@
+# Copyright (c) 2024 VEXXHOST, Inc.
+#
+# Licensed under the Apache License, Version 2.0 (the "License"); you may
+# not use this file except in compliance with the License. You may obtain
+# a copy of the License at
+#
+#      http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+
+from dunamai import Version
+
+project = "Atmosphere"
+copyright = "2024, VEXXHOST, Inc."
+author = "VEXXHOST, Inc."
+release = Version.from_git().serialize()
+
+# -- General configuration ---------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration
+
+extensions = ["sphinx_copybutton"]
+
+templates_path = ["_templates"]
+exclude_patterns = []
+
+
+# -- Options for HTML output -------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-output
+
+html_theme = "furo"
+html_static_path = ["_static"]
diff --git a/doc/source/config/index.rst b/doc/source/config/index.rst
new file mode 100644
index 0000000..6e6cb56
--- /dev/null
+++ b/doc/source/config/index.rst
@@ -0,0 +1,8 @@
+###################
+Configuration Guide
+###################
+
+.. toctree::
+   :maxdepth: 2
+
+   ingress
diff --git a/doc/source/config/ingress.rst b/doc/source/config/ingress.rst
new file mode 100644
index 0000000..7f31536
--- /dev/null
+++ b/doc/source/config/ingress.rst
@@ -0,0 +1,70 @@
+=======
+Ingress
+=======
+
+The ingress component is the primary entry point for all traffic to the cluster,
+it is currently deployed as an instance of ``ingress-nginx``.  It is tuned to work
+out of the box and should require no changes
+
+.. admonition:: Warning
+  :class: warning
+
+  The ingress component is a critical part of the cluster, and should be
+  managed with care.  Any changes to the ingress configuration should be
+  carefully reviewed and tested before being applied to the cluster.
+
+  If you make any changes to the ingress configuration, you may see a small
+  outage as the ingress controller is restarted.
+
+**********
+Helm Chart
+**********
+
+The ingress component is deployed using the ``ingress-nginx`` helm chart.  The
+chart is configured with a number of values to ensure it works correctly with
+the cluster out of the box, however, you can override these values by adding
+the following to your inventory:
+
+.. code-block:: yaml
+
+  ingress_nginx_helm_values:
+    foo: bar
+
+These values will be merged with the default values in the chart, and will be
+used to configure the ingress controller.
+
+***********************
+TLS Version and Ciphers
+***********************
+
+To provide the most secure baseline configuration possible, ``ingress-nginx``
+defaults to using TLS 1.2 and 1.3 only, with a `secure set of TLS ciphers <https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#ssl-ciphers>`_.
+
+Verifying TLS Version and Ciphers
+=================================
+
+In order to check the TLS version and ciphers used by the ingress controller,
+you can use the [sslscan](https://github.com/rbsec/sslscan) tool:
+
+.. code-block:: console
+
+  sslscan dashboard.cloud.example.com
+
+Legacy TLS
+==========
+
+The default configuration, though secure, does not support some older browsers
+and operating systems.
+
+In order to change this behaviour, you can make to make the following changes
+to the ``ingress_nginx_helm_values`` variable, the following example is using the
+`Mozilla SSL Configuration Generator <https://ssl-config.mozilla.org/#server=nginx&config=old>`_
+configured for the *old* profile:
+
+.. code-block:: yaml
+
+  ingress_nginx_helm_values:
+    controller:
+      config:
+        ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"
+        ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA"
diff --git a/doc/source/deploy/cinder.rst b/doc/source/deploy/cinder.rst
new file mode 100644
index 0000000..41a0bc2
--- /dev/null
+++ b/doc/source/deploy/cinder.rst
@@ -0,0 +1,178 @@
+####################
+Cinder Configuration
+####################
+
+Cinder, the block storage service for OpenStack, can be configured to use a
+variety of storage backends. This section guides you through setting up Cinder
+with different backend technologies, each of which might require specific
+configuration steps.
+
+********
+Ceph RBD
+********
+
+When using the integrated Ceph cluster provided with Atmosphere, no additional
+configuration is needed for Cinder. The deployment process automatically
+configures Cinder to use Ceph as the backend, simplifying setup and integration.
+
+***************
+Dell PowerStore
+***************
+
+In order to be able to use Dell PowerStore, you'll need to make sure that you
+setup the hosts inside of your storage array. You'll also need to make sure
+that they are not inside a host group or otherwise individual attachments will
+not work.
+
+You can enable the native PowerStore driver for Cinder with the following
+configuration inside your Ansible inventory:
+
+.. code-block:: yaml
+
+    cinder_helm_values:
+      storage: powerstore
+      dependencies:
+        static:
+          api:
+            jobs:
+              - cinder-db-sync
+              - cinder-ks-user
+              - cinder-ks-endpoints
+              - cinder-rabbit-init
+          scheduler:
+            jobs:
+              - cinder-db-sync
+              - cinder-ks-user
+              - cinder-ks-endpoints
+              - cinder-rabbit-init
+          volume:
+            jobs:
+              - cinder-db-sync
+              - cinder-ks-user
+              - cinder-ks-endpoints
+              - cinder-rabbit-init
+          volume_usage_audit:
+            jobs:
+              - cinder-db-sync
+              - cinder-ks-user
+              - cinder-ks-endpoints
+              - cinder-rabbit-init
+      conf:
+        cinder:
+          DEFAULT:
+            enabled_backends: powerstore
+            default_volume_type: powerstore
+        backends:
+          rbd1: null
+          powerstore:
+            volume_backend_name: powerstore
+            volume_driver: cinder.volume.drivers.dell_emc.powerstore.driver.PowerStoreDriver
+            san_ip: <FILL IN>
+            san_login: <FILL IN>
+            san_password: <FILL IN>
+            storage_protocol: <FILL IN> # FC or iSCSI
+      manifests:
+        deployment_backup: true
+        job_backup_storage_init: true
+        job_storage_init: false
+
+    nova_helm_values:
+      conf:
+        enable_iscsi: true
+
+.. admonition:: About ``conf.enable_iscsi``
+    :class: info
+
+    The ``enable_iscsi`` setting is required to allow the Nova instances to
+    expose volumes by making the `/dev` devices available to the containers,
+    not necessarily to use iSCSI as the storage protocol. In this case, the
+    PowerStore driver will use the storage protocol specified inside Cinder,
+
+********
+StorPool
+********
+
+Using StorPool as a storage backend requires additional configuration to ensure
+proper integration. These adjustments include network settings and file system mounts.
+
+Configure Cinder to use StorPool by implementing the following settings:
+
+.. code-block:: yaml
+
+    cinder_helm_values:
+      storage: storpool
+      pod:
+        useHostNetwork:
+          volume: true
+        mounts:
+          cinder_volume:
+            volumeMounts:
+              - name: etc-storpool-conf
+                mountPath: /etc/storpool.conf
+                readOnly: true
+              - name: etc-storpool-conf-d
+                mountPath: /etc/storpool.conf.d
+                readOnly: true
+            volumes:
+              - name: etc-storpool-conf
+                hostPath:
+                  type: File
+                  path: /etc/storpool.conf
+              - name: etc-storpool-conf-d
+                hostPath:
+                  type: Directory
+                  path: /etc/storpool.conf.d
+      dependencies:
+        static:
+          api:
+            jobs:
+              - cinder-db-sync
+              - cinder-ks-user
+              - cinder-ks-endpoints
+              - cinder-rabbit-init
+          scheduler:
+            jobs:
+              - cinder-db-sync
+              - cinder-ks-user
+              - cinder-ks-endpoints
+              - cinder-rabbit-init
+          volume:
+            jobs:
+              - cinder-db-sync
+              - cinder-ks-user
+              - cinder-ks-endpoints
+              - cinder-rabbit-init
+          volume_usage_audit:
+            jobs:
+              - cinder-db-sync
+              - cinder-ks-user
+              - cinder-ks-endpoints
+              - cinder-rabbit-init
+      conf:
+        cinder:
+          DEFAULT:
+            enabled_backends: hybrid-2ssd
+            default_volume_type: hybrid-2ssd
+        backends:
+          rbd1: null
+          hybrid-2ssd:
+            volume_backend_name: hybrid-2ssd
+            volume_driver: cinder.volume.drivers.storpool.StorPoolDriver
+            storpool_template: hybrid-2ssd
+            report_discard_supported: true
+      manifests:
+        deployment_backup: false
+        job_backup_storage_init: false
+        job_storage_init: false
+
+    nova_helm_values:
+      conf:
+        enable_iscsi: true
+
+.. admonition:: About ``conf.enable_iscsi``
+    :class: info
+
+    The ``enable_iscsi`` setting is required to allow the Nova instances to
+    expose volumes by making the `/dev` devices available to the containers,
+    not necessarily to use iSCSI as the storage protocol. In this case, the
+    StorPool devices will be exposed as block devices to the containers.
diff --git a/doc/source/deploy/csi.rst b/doc/source/deploy/csi.rst
new file mode 100644
index 0000000..fc89945
--- /dev/null
+++ b/doc/source/deploy/csi.rst
@@ -0,0 +1,56 @@
+#################
+CSI Configuration
+#################
+
+This section details how to configure Container Storage Interfaces (CSI) for
+your Kubernetes cluster that Atmosphere runs on. You will need to follow the
+steps below to enable specific CSI drivers based on your storage requirements.
+
+********
+Ceph RBD
+********
+
+If you are using the Ceph storage solution that Atmosphere deploys out of the
+box, no additional configuration is required. The necessary settings are
+automatically applied during the installation process.
+
+***************
+Dell PowerStore
+***************
+
+For environments requiring the integration of PowerStore for storage,
+configure the PowerStore CSI driver by updating your Ansible inventory as
+follows:
+
+.. code-block:: yaml
+
+    csi_driver: powerstore
+    powerstore_csi_config:
+      arrays:
+        - endpoint: https://<FILL IN>/api/rest
+          globalID: <FILL IN>
+          username: <FILL IN>
+          password: <FILL IN>
+          skipCertificateValidation: true
+          isDefault: true
+          blockProtocol: <FILL IN> # FC or iSCSI
+
+Ensure that you replace ``<FILL IN>`` with actual values relevant to your
+PowerStore configuration. This includes specifying the block protocol, which
+can either be Fibre Channel (FC) or iSCSI, depending on your network
+infrastructure.
+
+********
+StorPool
+********
+
+For environments requiring the integration of StorPool for storage, configure
+the StorPool CSI driver by updating your Ansible inventory as follows:
+
+.. code-block:: yaml
+
+    csi_driver: storpool
+    storpool_csi_template: k8s
+
+The ``storpool_csi_template`` variable specifies the StorPool template to use
+for the deployment which is set to ``k8s`` in the example above.
diff --git a/doc/source/deploy/glance.rst b/doc/source/deploy/glance.rst
new file mode 100644
index 0000000..f2f560b
--- /dev/null
+++ b/doc/source/deploy/glance.rst
@@ -0,0 +1,96 @@
+####################
+Glance Configuration
+####################
+
+Glance, the image service used by OpenStack, can be configured to use different
+storage backends depending on your deployment needs. This document provides
+guidance on setting up Glance with either the integrated Ceph cluster that
+comes with Atmosphere or using Cinder as a storage backend, with additional
+details for configurations that require special handling.
+
+****
+Ceph
+****
+
+The Atmosphere deployment includes a pre-configured Ceph cluster that is
+ready to use with Glance, requiring no additional configuration steps. This
+setup is recommended for most users as it provides a seamless and integrated
+storage solution.
+
+******
+Cinder
+******
+
+To configure Glance to use Cinder as its storage backend, which allows for
+managing images as block storage volumes, apply the following configuration:
+
+.. code-block:: yaml
+
+    glance_helm_values:
+      storage: cinder
+      conf:
+        glance:
+          glance_store:
+            stores: cinder
+            default_store: cinder
+          image_formats:
+            disk_formats: raw
+
+This configuration sets Cinder as the default and only storage backend for
+Glance, with images stored in the ``raw`` disk format.  The configuration
+above will use the Cinder default volume type for image storage.
+
+If you want to use a specific volume type, you can merge the following with
+the above configuration:
+
+.. code-block:: yaml
+
+    glance_helm_values:
+      conf:
+        glance:
+          glance_store:
+            cinder_volume_type: slow
+
+Vendor-Specific Configurations
+==============================
+
+Depending on the vendor you use for your Cinder storage backend, you may need
+to make some additional changes to accommodate specific requirements or
+capabilities offered by that vendor. Below are the configuration details for
+common providers.
+
+StorPool
+--------
+
+For deployments utilizing StorPool as the storage backend, additional
+configuration settings are necessary to ensure proper integration and
+functionality.  You can merge the following with the base Cinder configuration
+above:
+
+.. code-block:: yaml
+
+    glance_helm_values:
+      pod:
+        useHostNetwork:
+          api: true
+        mounts:
+          glance_api:
+            volumeMounts:
+              - name: etc-storpool-conf
+                mountPath: /etc/storpool.conf
+                readOnly: true
+              - name: etc-storpool-conf-d
+                mountPath: /etc/storpool.conf.d
+                readOnly: true
+            volumes:
+              - name: etc-storpool-conf
+                hostPath:
+                  type: File
+                  path: /etc/storpool.conf
+              - name: etc-storpool-conf-d
+                hostPath:
+                  type: Directory
+                  path: /etc/storpool.conf.d
+
+These adjustments include network settings and mounting necessary configuration
+files into the Glance API pod to interact efficiently with the StorPool backend.
diff --git a/doc/source/deploy/index.rst b/doc/source/deploy/index.rst
new file mode 100644
index 0000000..ff9238f
--- /dev/null
+++ b/doc/source/deploy/index.rst
@@ -0,0 +1,20 @@
+################
+Deployment Guide
+################
+
+Welcome to the Deployment Guide for the Atmosphere project. This guide provides
+detailed instructions and resources for setting up and configuring the
+Atmosphere deployment on a Kubernetes cluster.
+
+It is designed to assist you through the entire process, from initial system
+requirements to post-deployment verification, ensuring a successful installation
+and setup.
+
+.. toctree::
+   :maxdepth: 2
+
+   inventory
+   csi
+   cinder
+   glance
+   neutron
diff --git a/doc/source/deploy/inventory.rst b/doc/source/deploy/inventory.rst
new file mode 100644
index 0000000..62293ee
--- /dev/null
+++ b/doc/source/deploy/inventory.rst
@@ -0,0 +1,64 @@
+==================
+Building Inventory
+==================
+
+Atmosphere relies on an Ansible inventory in order to drive the deployment of
+all the components.
+
+In order to deploy Atmosphere, you will need to build a directory structure
+that will contain all the configuration files and secrets required to deploy
+the platform.
+
+The recommended layout is as follows:
+
+.. code-block:: text
+
+    cloud-config
+    ├── inventory
+    │   ├── group_vars
+    │   │   ├── all
+    │   │   │   ├── ceph.yml
+    │   │   │   ├── cluster_issuer.yml
+    │   │   │   ├── endpoints.yml
+    │   │   │   ├── keepalived.yml
+    │   │   │   ├── kube-prometheus-stack.yml
+    │   │   │   ├── kubernetes.yml
+    │   │   │   ├── neutron.yml
+    │   │   │   └── secrets.sops.yml
+    │   │   ├── cephs
+    │   │   │   └── osds.yml
+    │   └── hosts.ini
+    ├── playbooks
+    │   └── site.yml
+    └── requirements.yml
+
+*************
+``hosts.ini``
+*************
+
+The ``hosts.ini`` file is the Ansible inventory file that will be used to deploy
+the platform. It is recommended to use the following layout:
+
+.. code-block:: ini
+
+    [controllers]
+    ctl1.cloud.atmosphere.dev
+    ctl2.cloud.atmosphere.dev
+    ctl3.cloud.atmosphere.dev
+
+    [computes]
+    kvm1.cloud.atmosphere.dev
+    kvm2.cloud.atmosphere.dev
+    kvm3.cloud.atmosphere.dev
+
+    [cephs]
+    ceph1.cloud.atmosphere.dev
+    ceph2.cloud.atmosphere.dev
+    ceph3.cloud.atmosphere.dev
+
+.. admonition:: FQDNs are required!
+
+      The hostnames listed in the inventory file must be a FQDN that resolves to
+      the IP address of the host.  If they do not, you will have failures such
+      as agents failing to start, live migration failures and other transient
+      and hard to diagnose issues.
diff --git a/doc/source/deploy/neutron.rst b/doc/source/deploy/neutron.rst
new file mode 100644
index 0000000..f327e7a
--- /dev/null
+++ b/doc/source/deploy/neutron.rst
@@ -0,0 +1,200 @@
+#####################
+Neutron Configuration
+#####################
+
+Neutron, the network service for OpenStack, supports a variety of
+configurations to optimize and tailor network performance. This includes
+integrating hardware acceleration technologies to enhance networking
+capabilities within your OpenStack environment.
+
+*********************
+Hardware Acceleration
+*********************
+
+Hardware acceleration can significantly improve network performance by
+offloading specific network functions to directly to the network interface
+card (NIC). This reduces the load on the host CPU and improves network
+throughput and latency.
+
+ML2/OVS
+=======
+
+Mellanox Accelerated Switching And Packet Processing (ASAP\ :sup:`2`)
+---------------------------------------------------------------------
+
+Mellanox ASAP\ :sup:`2` is a technology that enables the offloading of the Open vSwitch
+datapath to the NIC. This offloading is done by the NIC's firmware, and is
+transparent to the host.
+
+Atmosphere uses the `netoffload <https://github.com/vexxhost/netoffload>`_
+project which takes care of validating and preparing the host for SR-IOV.
+
+It is recommended to follow the ``netoffload`` `BIOS, Kernel & NIC configuration <https://github.com/vexxhost/netoffload#bios-configuration>`_
+steps documented before getting started.
+
+Open vSwitch configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In order to enable hardware off-loading in Open vSwitch, you must make sure that
+you deploy with the following configuration:
+
+.. code-block:: yaml
+
+    openvswitch_helm_values:
+      conf:
+        ovs_hw_offload:
+          enabled: true
+
+Neutron configuration
+^^^^^^^^^^^^^^^^^^^^^
+
+In order to enable hardware off-loading in Neutron, you can simply deploy it
+with the following configuration and it will use `netoffload <https://github.com/vexxhost/netoffload>`_
+to automatically configure ASAP\ :sup:`2`.
+
+.. admonition:: About ``Init`` errors
+    :class: info
+
+    If you see an Init error when deploying Neutron, you may need to look at the
+    logs of the ``netoffload`` container to see what went wrong.
+
+.. code-block:: yaml
+
+    neutron_helm_values:
+      conf:
+        netoffload:
+          asap2:
+            - dev: enp97s0f0
+              vfs: 16
+
+ML2/OVN
+=======
+
+DPDK for provider & tenant networks
+-----------------------------------
+
+DPDK is a set of libraries and drivers for fast packet processing. It is
+designed to run mostly in userspace, and can be used to accelerate network
+functions in OpenStack.
+
+DPDK can be used with OVN to accelerate the processing of packets in the
+datapath. This can be done by enabling the DPDK support in the OVN
+configuration.
+
+Open vSwitch configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In order to enable hardware off-loading in Open vSwitch, you must make sure that
+you deploy with the following configuration:
+
+.. code-block:: yaml
+
+    openvswitch_helm_values:
+      conf:
+        ovs_dpdk:
+          enabled: true
+          socket_memory: 2048
+          hugepages_mountpath: /dev/hugepages
+          vhostuser_socket_dir: vhostuser
+          lcore_mask: 0x1
+          driver: mlx5_core
+          vhost_iommu_support: true
+
+For more details about configuring `socket_memory`, `lcore_mask`, and `driver`
+parameters, please refer to the `OpenvSwitch documentation <https://docs.openvswitch.org/en/latest/intro/install/dpdk/#setup-ovs>`_.
+
+OVN configuration
+^^^^^^^^^^^^^^^^^
+
+In order to enable hardware off-loading in OVN, you must make sure that
+you deploy with the following configuration:
+
+.. code-block:: yaml
+
+    ovn_helm_values:
+      network:
+        interface:
+          tunnel: br-ex
+          tunnel_network_cidr: 192.168.0.0/19
+      conf:
+        ovn_bridge_mappings: external:br-ex
+        ovn_bridge_datapath_type: netdev
+
+Neutron configuration
+^^^^^^^^^^^^^^^^^^^^^
+
+In order to enable hardware off-loading in Neutron, you can simply deploy it
+with the following configuration and it will take care of creating the
+DPDK interfaces for you.
+
+.. code-block:: yaml
+
+    neutron_helm_values:
+      conf:
+        neutron:
+          DEFAULT:
+            global_physnet_mtu: 9100
+        plugins:
+          ml2_conf:
+            ml2:
+              path_mtu: 9100
+              physical_network_mtus: external:9100
+            ml2_type_vxlan:
+              vni_ranges: 2000:1000000
+        ovs_dpdk:
+          enabled: true
+          update_dpdk_bond_config: true
+          driver: mlx5_core
+          bonds:
+            - name: dpdkbond
+              bridge: br-ex
+              migrate_ip: true
+              mtu: 9100
+              n_rxq: 2
+              n_txq: 2
+              n_rxq_size: 2048
+              n_txq_size: 2048
+              vhost_iommu_support: true
+              ovs_options: 'bond_mode=balance-tcp lacp=active bond_updelay=10 bond_downdelay=10 other_config:lacp-time=fast'
+              nics:
+                - name: dpdk_b0s0
+                  pci_id: '0000:c1:00.0'
+                - name: dpdk_b0s1
+                  pci_id: '0000:c1:00.1'
+          modules:
+            - name: dpdk
+              log_level: info
+          nics: null
+
+Flavor configuration
+^^^^^^^^^^^^^^^^^^^^
+
+In order to use DPDK with OVN, you must create a flavor that supports DPDKw
+which also includes making changes for the services that use the service
+virtual machine model such as Octavia and Manila.
+
+.. code-block:: yaml
+
+    nova_flavors:
+      - disk: 1
+        name: m1.tiny
+        ram: 512
+        vcpus: 1
+        extra_specs:
+          "hw:vif_multiqueue_enabled": 'true'
+          "hw:mem_page_size": 'large'
+      - disk: 20
+        name: m1.small
+        ram: 2048
+        vcpus: 1
+        extra_specs:
+          "hw:vif_multiqueue_enabled": 'true'
+          "hw:mem_page_size": 'large'
+
+    manila_flavor_extra_specs:
+      "hw:vif_multiqueue_enabled": 'true'
+      "hw:mem_page_size": large
+
+    octavia_amphora_flavor_extra_specs:
+      "hw:vif_multiqueue_enabled": 'true'
+      "hw:mem_page_size": large
diff --git a/doc/source/index.rst b/doc/source/index.rst
new file mode 100644
index 0000000..f7150fc
--- /dev/null
+++ b/doc/source/index.rst
@@ -0,0 +1,38 @@
+##########
+Atmosphere
+##########
+
+Atmosphere is an advanced OpenStack distribution that is powered by open source
+technologies & built by `VEXXHOST <https://vexxhost.com>`_ powered by Kuberentes,
+which allows you to easily deliver virtual machines, Kubernetes and bare-metal
+on your on-premise hardware.
+
+The difference between Atmosphere and other deployment tools is that it is
+fully open source with batteries included.  It ships with settings that are
+curated by years of experience from our team alongside other features such as:
+
+- Built on top of Kubernetes for the life-cycle of the OpenStack cloud.
+- Native integration with Keycloak for robust identity management.
+- Native integration with `Cluster API driver for Magnum <https://github.com/vexxhost/magnum-cluster-api>`_
+- Simplified deployment and management of the cloud using Kubernetes.
+- Pre-integrated with many popular OpenStack projects with no additional configuration.
+- Native integration with many storage platforms out of the box.
+- Full day 2 operations for monitoring, logging and alerting out of the box using Prometheus, AlertManager, Grafana, Loki and more.
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Contents:
+
+   quick-start
+   config/index
+   deploy/index
+   admin/index
+
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
diff --git a/doc/source/quick-start.rst b/doc/source/quick-start.rst
new file mode 100644
index 0000000..9479f25
--- /dev/null
+++ b/doc/source/quick-start.rst
@@ -0,0 +1,228 @@
+###########
+Quick Start
+###########
+
+There are several ways that you can quickly get started with Atmosphere to explore
+it's capabilities.
+
+**********
+Deployment
+**********
+
+This section covers all of the different ways you can deploy a quick start
+environment for Atmosphere.
+
+.. admonition:: Testing & Development Only
+    :class: info
+
+    The quick start installation is not for production use, it's perfect
+    for testing and development.
+
+All-in-one
+==========
+
+The easiest way to get started with Atmosphere is to deploy the all-in-one
+installation.  This will install an entire stack of Atmosphere, with Ceph
+and all the OpenStack services inside a single machine.
+
+.. admonition:: Non-reversible Changes
+    :class: warning
+
+    The all-in-one will fully take-over the machine by making system-level
+    changes.  It's recommended to run it inside a virtual machine or a
+    physical machine that can be dedicated to this purpose.
+
+In order to get started, you'll need a **Ubuntu 22.04** system with the
+following minimum system requirements:
+
+- Cores: 8 threads (or vCPUs)
+- Memory: 32GB
+
+If you're looking to run Kubernetes clusters, you'll need more memory
+for the workloads, it following minimum is recommended (but more memory
+is always better!):
+
+- Cores: 16 threads (or vCPUs)
+- Memory: 64GB
+
+.. admonition:: Nested Virtualization
+    :class: warning
+
+    If you're running this inside a virtual machine, it is **extremely**
+    important that the virtual machines supported nested virtualization,
+    otherwise the performance of the VMs will be un-usable.
+
+You'll need to start all of the necessary dependencies first:
+
+.. code-block:: bash
+
+    $ sudo apt-get update
+    $ sudo apt-get install git python3-pip
+    $ sudo pip install poetry
+
+Once done, you can clone the repository locally and switch to the
+``atmosphere`` directory:
+
+.. code-block:: bash
+
+    $ git clone https://github.com/vexxhost/atmosphere.git
+    $ cd atmosphere
+
+Once you're in the directory, you can deploy the all-in-one environment
+by running the following command:
+
+.. code-block:: bash
+
+    $ cd atmosphere
+    $ sudo poetry install --with dev
+    $ sudo poetry run molecule converge -s aio
+
+Once the deployment is done, it will have a full deployment of all services
+inside the same host, so you can use the cloud from the same machine by
+referencing the usage section.
+
+Multi-node
+==========
+
+The multi-node intends to provide the most near-production experience possible,
+as it is architected purely towards production-only environments. In order to
+get a quick production-ready experience of Atmosphere, this will deploy a full
+stack of Atmosphere, with Ceph and all the OpenStack services across multiple
+machines in a lab environment.
+
+OpenStack
+---------
+
+You can deploy Atmosphere on top of an existing OpenStack environment where many
+virtual machines will be deployed in the same way that you'd have multiple
+physical machines in a datacenter for a production environment.
+
+The quick start is powered by Molecule and it is used in continuous integration
+running against the VEXXHOST public cloud so that would be an easy target to
+use to try it out.
+
+ou will need the following quotas set up in your cloud account:
+
+* 8 instances
+* 32 cores
+* 128GB RAM
+* 360GB storage
+
+These resources will be used to create a total of 8 instances broken up as
+follows:
+
+* 3 Controller nodes
+* 3 Ceph OSD nodes
+* 2 Compute nodes
+
+First of all, you'll have to make sure you clone the repository locally to your
+system with `git` by running the following command:
+
+.. code-block:: console
+
+    $ git clone https://github.com/vexxhost/atmosphere
+
+You will need ``poetry`` installed on your operating system.  You will need to make
+sure that you have the appropriate OpenStack environment variables set (such
+as ``OS_CLOUD`` or ``OS_AUTH_URL``, etc.).  You can also use the following
+environment variables to tweak the behaviour of the Heat stack that is created:
+
+* ``ATMOSPHERE_STACK_NAME``: The name of the Heat stack to be created (defaults to
+  `atmosphere`).
+* ``ATMOSPHERE_PUBLIC_NETWORK``: The name of the public network to attach floating
+  IPs from (defaults to ``public``).
+* ``ATMOSPHERE_IMAGE``: The name or UUID of the image to be used for deploying the
+  instances (defaults to ``Ubuntu 20.04.3 LTS (x86_64) [2021-10-04]``).
+* ``ATMOSPHERE_INSTANCE_TYPE``(Deprecated): The instance type used to deploy all of the
+  different instances.(It doesn't have its own default value.)
+  This has been deprecated from v1.4.0. You can configure the instance type per a
+  machine role using ``ATMOSPHERE_CONTROLLER_INSTANCE_TYPE``,
+  ``ATMOSPHERE_COMPUTE_INSTANCE_TYPE``, and ``ATMOSPHERE_STORAGE_INSTANCE_TYPE``
+  variables. For backwards compatibility, if variables specific to the machine roles
+  are not set and ``ATMOSPHERE_INSTANCE_TYPE`` is set, ``ATMOSPHERE_INSTANCE_TYPE`` value
+  is used.
+* ``ATMOSPHERE_CONTROLLER_INSTANCE_TYPE``: The instance type used to deploy controller
+  instances (defaults to ``v3-standard-16``).
+* ``ATMOSPHERE_COMPUTE_INSTANCE_TYPE``: The instance type used to deploy compute
+  instances (defaults to ``v3-standard-4``).
+* ``ATMOSPHERE_STORAGE_INSTANCE_TYPE``: The instance type used to deploy storage
+  instances (defaults to ``v3-standard-4``).
+* ``ATMOSPHERE_NAMESERVERS``: A comma-separated list of nameservers to be used for
+  the instances (defaults to ``1.1.1.1``).
+* ``ATMOSPHERE_USERNAME``: The username what is used to login into the instances (
+  defaults to ``ubuntu``).
+* ``ATMOSPHERE_DNS_SUFFIX_NAME``: The DNS domainname that is used for the API and
+  Horizon. (defaults to ``nip.io``).
+* ``ATMOSPHERE_ACME_SERVER``: The ACME server, currenly this is from LetsEncrypt,
+  with StepCA from SmallStep it is possible to run a internal ACME server.
+  The CA of that ACME server should be present in the instance image.
+* ``ATMOSPHERE_ANSIBLE_VARS_PATH``: The path for ansible group_vars and host_vars.
+  This to build a multinode development cluster with own configs, that are not
+  generated by molecule. This way you can test your configs before you bring
+  them to production.
+
+Once you're ready to get started, you can run the following command to install
+poetry dependencies:
+
+.. code-block:: console
+
+    $ poetry install
+
+Then you can run the following command to build the Heat stack:
+
+.. code-block:: console
+
+    $ poetry run molecule converge
+
+This will create a Heat stack with the name `atmosphere` and start deploying
+the cloud.  Once it's complete, you can login to any of the systems by using
+the `login` sub-command.  For exampel, to login to the first controller node,
+you can run the following:
+
+.. code-block:: console
+
+    $ poetry run molecule login -h ctl1
+
+At this point, you can proceed to the usage section to see how to interact
+with the cloud.
+
+Once you're done with your environment and you need to tear it down, you can
+use the `destroy` sub-command:
+
+.. code-block:: console
+
+    $ poetry run molecule destroy
+
+For more information about the different commands used by Molecule, you can
+refer to the Molecule documentation.
+
+*****
+Usage
+*****
+
+Once the deployment is done, you can either use the CLI to interact with
+the OpenStack environment, or you can access the Horizon dashboard.
+
+For the CLI, you can ``source /root/openrc`` and then use the ``openstack``
+CLI.  For example, if you want to list the networks, you can run the
+following command:
+
+.. code-block:: console
+
+    $ source /root/openrc
+    $ openstack network list
+
+For the Horizon dashboard, you can find the URL to access it by running
+the following command:
+
+.. code-block:: console
+
+    $ kubectl -n openstack get ingress/dashboard -ojsonpath='{.spec.rules[0].host}'
+
+You can find the credentials to login to the dashboard reading the
+`/root/openrc` file.  You can use the following variables to match
+the credentials:
+
+- Username: ``OS_USERNAME``
+- Password: ``OS_PASSWORD``
+- Domain: ``OS_USER_DOMAIN_NAME``