diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/release/installation/virtual.rst | 79 |
1 files changed, 73 insertions, 6 deletions
diff --git a/docs/release/installation/virtual.rst b/docs/release/installation/virtual.rst index 5682f364..a844d43f 100644 --- a/docs/release/installation/virtual.rst +++ b/docs/release/installation/virtual.rst @@ -3,10 +3,23 @@ Installation High-Level Overview - Virtual Deployment Deploying virtually is an alternative deployment method to bare metal, where only a single bare metal Jump Host server is required to execute deployment. -In this deployment type, the Jump Host server will host the undercloud VM along -with any number of OPNFV overcloud control/compute nodes. This deployment type -is useful when physical resources are constrained, or there is a desire to -deploy a temporary sandbox environment. +This deployment type is useful when physical resources are constrained, or +there is a desire to deploy a temporary sandbox environment. + +With virtual deployments, two deployment options are offered. The first is a +standard deployment where the Jump Host server will host the undercloud VM along +with any number of OPNFV overcloud control/compute nodes. This follows the same +deployment workflow as baremetal, and can take between 1 to 2 hours to complete. + +The second option is to use snapshot deployments. Snapshots are saved disk images +of previously deployed OPNFV upstream. These snapshots are promoted daily and contain +and already deployed OPNFV environment that has passed a series of tests. The +advantage of the snapshot is that it deploys in less than 10 minutes. Another +major advantage is that the snapshots work on both CentOS and Fedora OS. Note: +Fedora support is only tested via PIP installation at this time and not via RPM. + +Standard Deployment Overview +---------------------------- The virtual deployment operates almost the same way as the bare metal deployment with a few differences mainly related to power management. @@ -27,6 +40,23 @@ the power management. Finally, the default network settings file will deploy wi modification. Customizations are welcome but not needed if a generic set of network settings are acceptable. +Snapshot Deployment Overview +---------------------------- + +Snapshot deployments use the same ``opnfv-deploy`` CLI as standard deployments. +The snapshot deployment will use a cache in order to store snapshots that are +downloaded from the internet at deploy time. This caching avoids re-downloading +the same artifact between deployments. The snapshot deployment recreates the same +network and libvirt setup as would have been provisioned by the Standard +deployment, with the exception that there is no undercloud VM. The snapshot +deployment will give the location of the RC file to use in order to interact +with the Overcloud directly from the jump host. + +Snapshots come in different topology flavors. One is able to deploy either HA +(3 Control, 2 Computes, no-HA (1 Control, 2 Computes), or all-in-one +(1 Control/Compute. The snapshot deployment itself is always done with the +os-odl-nofeature-* scenario. + Installation Guide - Virtual Deployment ======================================= @@ -57,8 +87,8 @@ Install Jump Host Follow the instructions in the `Install Bare Metal Jump Host`_ section. -Running ``opnfv-deploy`` ------------------------- +Running ``opnfv-deploy`` for Standard Deployment +------------------------------------------------ You are now ready to deploy OPNFV! ``opnfv-deploy`` has virtual deployment capability that includes all of @@ -96,6 +126,43 @@ Follow the steps below to execute: 3. When the deployment is complete the IP for the undercloud and a url for the OpenStack dashboard will be displayed +Running ``opnfv-deploy`` for Snapshot Deployment +------------------------------------------------ + +Deploying snapshots requires enough disk space to cache snapshot archives, as well +as store VM disk images per deployment. The snapshot cache directory can be +configured at deploy time. Ensure a directory is used on a partition with enough +space for about 20GB. Additionally, Apex will attempt to detect the default +libvirt storage pool on the jump host. This is typically '/var/lib/libvirt/images'. +On default CentOS installations, this path will resolve to the /root partition, +which is only around 50GB. Therefore, ensure that the path for the default storage +pool has enough space to hold the VM backing storage (approx 4GB per VM). Note, +each Overcloud VM disk size is set to 40GB, however Libvirt grows these disks +dynamically. Due to this only 4GB will show up at initial deployment, but the disk +may grow from there up to 40GB. + +The new arguments to deploy snapshots include: + + - `--snapshot`: Enables snapshot deployments + - `--snap-cache`: Indicates the directory to use for caching artifacts + +An example deployment command is: + +.. code-block:: + + opnfv-deploy -d ../config/deploy/os-odl-queens-noha.yaml --snapshot + --snap-cache /home/trozet/snap_cache --virtual-computes 0 --no-fetch + +In the above example, several of the Standard Deployment arguments are still +used to deploy snapshots: + + - `-d`: Deploy settings are used to determine OpenStack version of snapshots + to use as well as the topology + - `--virtual-computes` - When set to 0, it indicates to Apex to use an + all-in-one snapshot + - `--no-fetch` - Can be used to disable fetching latest snapshot artifact + from upstream and use the latest found in `--snap-cache` + Verifying the Setup - VMs ------------------------- |