summaryrefslogtreecommitdiffstats
path: root/docs/release/installation
diff options
context:
space:
mode:
Diffstat (limited to 'docs/release/installation')
-rw-r--r--docs/release/installation/abstract.rst8
-rw-r--r--docs/release/installation/architecture.rst35
-rw-r--r--docs/release/installation/baremetal.rst54
-rw-r--r--docs/release/installation/index.rst3
-rw-r--r--docs/release/installation/introduction.rst29
-rw-r--r--docs/release/installation/references.rst4
-rw-r--r--docs/release/installation/requirements.rst4
-rw-r--r--docs/release/installation/troubleshooting.rst10
-rw-r--r--docs/release/installation/upstream.rst101
-rw-r--r--docs/release/installation/virtual.rst97
10 files changed, 266 insertions, 79 deletions
diff --git a/docs/release/installation/abstract.rst b/docs/release/installation/abstract.rst
index 534d8a8..2d55c15 100644
--- a/docs/release/installation/abstract.rst
+++ b/docs/release/installation/abstract.rst
@@ -1,16 +1,16 @@
Abstract
========
-This document describes how to install the Euphrates release of OPNFV when
+This document describes how to install the Gambia release of OPNFV when
using Apex as a deployment tool covering it's limitations, dependencies
and required system resources.
License
=======
-Euphrates release of OPNFV when using Apex as a deployment tool Docs
-(c) by Tim Rozet (Red Hat) and Dan Radez (Red Hat)
+Gambia release of OPNFV when using Apex as a deployment tool Docs
+(c) by Tim Rozet (Red Hat)
-Euphrates release of OPNFV when using Apex as a deployment tool Docs
+Gambia release of OPNFV when using Apex as a deployment tool Docs
are licensed under a Creative Commons Attribution 4.0 International License.
You should have received a copy of the license along with this.
If not, see <http://creativecommons.org/licenses/by/4.0/>.
diff --git a/docs/release/installation/architecture.rst b/docs/release/installation/architecture.rst
index 079c26d..0bf2d3b 100644
--- a/docs/release/installation/architecture.rst
+++ b/docs/release/installation/architecture.rst
@@ -16,8 +16,7 @@ deploy the overcloud.
The undercloud is the all-in-one installation of OpenStack that includes
baremetal provisioning capability. The undercloud will be deployed as a
-virtual machine on a Jump Host. This VM is pre-built and distributed as part
-of the Apex RPM.
+virtual machine on a Jump Host.
The overcloud is OPNFV. Configuration will be passed into undercloud and
the undercloud will use OpenStack's orchestration component, named Heat, to
@@ -127,26 +126,26 @@ issues per scenario. The following scenarios correspond to a supported
+-------------------------+-------------+---------------+
| os-nosdn-nofeature-noha | Apex | Yes |
+-------------------------+-------------+---------------+
-| os-nosdn-bar-ha | Barometer | Yes |
+| os-nosdn-bar-ha | Barometer | No |
+-------------------------+-------------+---------------+
-| os-nosdn-bar-noha | Barometer | Yes |
+| os-nosdn-bar-noha | Barometer | No |
+-------------------------+-------------+---------------+
| os-nosdn-calipso-noha | Calipso | Yes |
+-------------------------+-------------+---------------+
-| os-nosdn-ovs_dpdk-ha | Apex | Yes |
+| os-nosdn-ovs_dpdk-ha | Apex | No |
+-------------------------+-------------+---------------+
-| os-nosdn-ovs_dpdk-noha | Apex | Yes |
+| os-nosdn-ovs_dpdk-noha | Apex | No |
+-------------------------+-------------+---------------+
| os-nosdn-fdio-ha | FDS | No |
+-------------------------+-------------+---------------+
| os-nosdn-fdio-noha | FDS | No |
+-------------------------+-------------+---------------+
-| os-nosdn-kvm_ovs_dpdk-ha| KVM for NFV | Yes |
+| os-nosdn-kvm_ovs_dpdk-ha| KVM for NFV | No |
+-------------------------+-------------+---------------+
-| os-nosdn-kvm_ovs_dpdk | KVM for NFV | Yes |
+| os-nosdn-kvm_ovs_dpdk | KVM for NFV | No |
| -noha | | |
+-------------------------+-------------+---------------+
-| os-nosdn-performance-ha | Apex | Yes |
+| os-nosdn-performance-ha | Apex | No |
+-------------------------+-------------+---------------+
| os-odl-nofeature-ha | Apex | Yes |
+-------------------------+-------------+---------------+
@@ -160,7 +159,15 @@ issues per scenario. The following scenarios correspond to a supported
+-------------------------+-------------+---------------+
| os-odl-bgpvpn-noha | SDNVPN | Yes |
+-------------------------+-------------+---------------+
-| os-odl-sfc-ha | SFC | No |
+| os-odl-sriov-ha | Apex | No |
++-------------------------+-------------+---------------+
+| os-odl-sriov-noha | Apex | No |
++-------------------------+-------------+---------------+
+| os-odl-l2gw-ha | Apex | No |
++-------------------------+-------------+---------------+
+| os-odl-l2gw-noha | Apex | No |
++-------------------------+-------------+---------------+
+| os-odl-sfc-ha | SFC | Yes |
+-------------------------+-------------+---------------+
| os-odl-sfc-noha | SFC | Yes |
+-------------------------+-------------+---------------+
@@ -168,9 +175,9 @@ issues per scenario. The following scenarios correspond to a supported
+-------------------------+-------------+---------------+
| os-odl-csit-noha | Apex | No |
+-------------------------+-------------+---------------+
-| os-odl-fdio-ha | FDS | Yes |
+| os-odl-fdio-ha | FDS | No |
+-------------------------+-------------+---------------+
-| os-odl-fdio-noha | FDS | Yes |
+| os-odl-fdio-noha | FDS | No |
+-------------------------+-------------+---------------+
| os-odl-fdio_dvr-ha | FDS | No |
+-------------------------+-------------+---------------+
@@ -180,5 +187,7 @@ issues per scenario. The following scenarios correspond to a supported
+-------------------------+-------------+---------------+
| os-onos-sfc-ha | ONOSFW | No |
+-------------------------+-------------+---------------+
-| os-ovn-nofeature-noha | Apex | Yes |
+| os-ovn-nofeature-noha | Apex | No |
++-------------------------+-------------+---------------+
+| os-ovn-nofeature-ha | Apex | Yes |
+-------------------------+-------------+---------------+
diff --git a/docs/release/installation/baremetal.rst b/docs/release/installation/baremetal.rst
index 49997f8..efea0f8 100644
--- a/docs/release/installation/baremetal.rst
+++ b/docs/release/installation/baremetal.rst
@@ -46,11 +46,17 @@ and report the properties of it back to the undercloud node.
After introspection the undercloud will execute a Heat Stack Deployment to
continue node provisioning and configuration. The nodes will reboot and PXE
from the undercloud PXE server again to provision each node using Glance disk
-images provided by the undercloud. These disk images include all the necessary
-packages and configuration for an OPNFV deployment to execute. Once the disk
+images provided by the undercloud. These disk images include all the necessary
+packages and configuration for an OPNFV deployment to execute. Once the disk
images have been written to node's disks the nodes will boot locally and
-execute cloud-init which will execute the final node configuration. This
-configuration is largely completed by executing a puppet apply on each node.
+execute cloud-init which will execute the final node configuration. At this
+point in the deployment, the Heat Stack will complete, and Mistral will
+takeover the configuration of the nodes. Mistral handles calling Ansible which
+will connect to each node, and begin configuration. This configuration includes
+launching the desired OPNFV services as containers, and generating their
+configuration files. These configuration is largely completed by executing a
+puppet apply on each container to generate the config files, which are then
+stored on the overcloud host and mounted into the service container at runtime.
Installation Guide - Bare Metal Deployment
==========================================
@@ -62,11 +68,7 @@ Install Bare Metal Jump Host
----------------------------
1a. If your Jump Host does not have CentOS 7 already on it, or you would like
- to do a fresh install, then download the Apex bootable ISO from the OPNFV
- artifacts site <http://artifacts.opnfv.org/apex.html>. There have been
- isolated reports of problems with the ISO having trouble completing
- installation successfully. In the unexpected event the ISO does not work
- please workaround this by downloading the CentOS 7 DVD and performing a
+ to do a fresh install, then download the CentOS 7 DVD and perform a
"Virtualization Host" install. If you perform a "Minimal Install" or
install type other than "Virtualization Host" simply run
``sudo yum -y groupinstall "Virtualization Host"``
@@ -84,11 +86,11 @@ Install Bare Metal Jump Host
Replace /dev/sdX with the device assigned to your usb drive. Then select
the USB device as the boot media on your Jump Host
-2a. When not using the OPNFV Apex ISO, install these repos:
+2a. Install these repos:
- ``sudo yum install https://repos.fedorapeople.org/repos/openstack/openstack-pike/rdo-release-pike-1.noarch.rpm``
+ ``sudo yum install https://repos.fedorapeople.org/repos/openstack/openstack-queens/rdo-release-queens-1.noarch.rpm``
``sudo yum install epel-release``
- ``sudo curl -o /etc/yum/repos.d/opnfv-apex.repo http://artifacts.opnfv.org/apex/euphrates/opnfv-apex.repo``
+ ``sudo curl -o /etc/yum.repos.d/opnfv-apex.repo http://artifacts.opnfv.org/apex/gambia/opnfv-apex.repo``
The RDO Project release repository is needed to install OpenVSwitch, which
is a dependency of opnfv-apex. If you do not have external connectivity to
@@ -97,14 +99,12 @@ Install Bare Metal Jump Host
opnfv-apex repo hosts all of the Apex dependencies which will automatically
be installed when installing RPMs, but will be pre-installed with the ISO.
-2b. If you chose not to use the Apex ISO, then you must download and install
- the Apex RPMs to the Jump Host. Download the first 3 Apex RPMs from the
- OPNFV downloads page, under the TripleO RPMs
- ``https://www.opnfv.org/software/downloads``.
+2b. Download the first Apex RPMs from the OPNFV downloads page, under the
+ TripleO RPMs ``https://www.opnfv.org/software/downloads``. The dependent
+ RPMs will be automatically installed from the opnfv-apex repo in the
+ previous step.
The following RPMs are available for installation:
- - opnfv-apex - OpenDaylight, OVN, and nosdn support
- - opnfv-apex-undercloud - (reqed) Undercloud Image
- python34-opnfv-apex - (reqed) OPNFV Apex Python package
- python34-markupsafe - (reqed) Dependency of python34-opnfv-apex **
- python34-jinja2 - (reqed) Dependency of python34-opnfv-apex **
@@ -123,9 +123,9 @@ Install Bare Metal Jump Host
automatically installed by installing python34-opnfv-apex when the
opnfv-apex.repo has been previously downloaded to ``/etc/yum.repos.d/``.
- Install the three required RPMs (replace <rpm> with the actual downloaded
+ Install the required RPM (replace <rpm> with the actual downloaded
artifact):
- ``yum -y install <opnfv-apex.rpm> <opnfv-apex-undercloud> <python34-opnfv-apex>``
+ ``yum -y install <python34-opnfv-apex>``
3. After the operating system and the opnfv-apex RPMs are installed, login to
your Jump Host as root.
@@ -150,9 +150,13 @@ IPMI configuration information gathered in section
template to ``/etc/opnfv-apex/inventory.yaml``.
2. The nodes dictionary contains a definition block for each baremetal host
- that will be deployed. 1 or more compute nodes and 3 controller nodes are
- required. (The example file contains blocks for each of these already).
+ that will be deployed. 0 or more compute nodes and 1 or 3 controller nodes
+ are required (the example file contains blocks for each of these already).
It is optional at this point to add more compute nodes into the node list.
+ By specifying 0 compute nodes in the inventory file, the deployment will
+ automatically deploy "all-in-one" nodes which means the compute will run
+ along side the controller in a single overcloud node. Specifying 3 control
+ nodes will result in a highly-available service model.
3. Edit the following values for each node:
@@ -224,7 +228,7 @@ Follow the steps below to execute:
network_settings.yaml allows you to customize your networking topology.
Note it can also be useful to run the command with the ``--debug``
argument which will enable a root login on the overcloud nodes with
- password: 'opnfv-apex'. It is also useful in some cases to surround the
+ password: 'opnfvapex'. It is also useful in some cases to surround the
deploy command with ``nohup``. For example:
``nohup <deploy command> &``, will allow a deployment to continue even if
ssh access to the Jump Host is lost during deployment.
@@ -238,5 +242,5 @@ Follow the steps below to execute:
3. When the deployment is complete the undercloud IP and overcloud dashboard
url will be printed. OPNFV has now been deployed using Apex.
-.. _`Execution Requirements (Bare Metal Only)`: index.html#execution-requirements-bare-metal-only
-.. _`Network Requirements`: index.html#network-requirements
+.. _`Execution Requirements (Bare Metal Only)`: requirements.html#execution-requirements-bare-metal-only
+.. _`Network Requirements`: requirements.html#network-requirements
diff --git a/docs/release/installation/index.rst b/docs/release/installation/index.rst
index 8fb4946..443aef6 100644
--- a/docs/release/installation/index.rst
+++ b/docs/release/installation/index.rst
@@ -16,13 +16,14 @@ Contents:
requirements.rst
baremetal.rst
virtual.rst
+ upstream.rst
verification.rst
troubleshooting.rst
references.rst
:Authors: Tim Rozet (trozet@redhat.com)
:Authors: Dan Radez (dradez@redhat.com)
-:Version: 5.0
+:Version: 7.1
Indices and tables
==================
diff --git a/docs/release/installation/introduction.rst b/docs/release/installation/introduction.rst
index bb220b7..706e226 100644
--- a/docs/release/installation/introduction.rst
+++ b/docs/release/installation/introduction.rst
@@ -1,8 +1,8 @@
Introduction
============
-This document describes the steps to install an OPNFV Euphrates reference
-platform, as defined by the Genesis Project using the Apex installer.
+This document describes the steps to install an OPNFV Gambia reference
+platform using the Apex installer.
The audience is assumed to have a good background in networking
and Linux administration.
@@ -12,31 +12,22 @@ Preface
Apex uses Triple-O from the RDO Project OpenStack distribution as a
provisioning tool. The Triple-O image based life cycle installation
-tool provisions an OPNFV Target System (3 controllers, 2 or more
+tool provisions an OPNFV Target System (1 or 3 controllers, 0 or more
compute nodes) with OPNFV specific configuration provided by the Apex
deployment tool chain.
The Apex deployment artifacts contain the necessary tools to deploy and
configure an OPNFV target system using the Apex deployment toolchain.
-These artifacts offer the choice of using the Apex bootable ISO
-(``opnfv-apex-euphrates.iso``) to both install CentOS 7 and the
-necessary materials to deploy or the Apex RPMs (``opnfv-apex*.rpm``),
-and their associated dependencies, which expects installation to a
-CentOS 7 libvirt enabled host. The RPM contains a collection of
-configuration files, prebuilt disk images, and the automatic deployment
-script (``opnfv-deploy``).
+The Apex artifact is a python package capable of automating the installation of
+TripleO and other OPNFV components.
-An OPNFV install requires a "Jump Host" in order to operate. The bootable
-ISO will allow you to install a customized CentOS 7 release to the Jump Host,
+An OPNFV install requires a "Jump Host" in order to operate. It is required
+to install CentOS 7 release to the Jump Host for traditional deployment,
which includes the required packages needed to run ``opnfv-deploy``.
If you already have a Jump Host with CentOS 7 installed, you may choose to
-skip the ISO step and simply install the (``opnfv-apex*.rpm``) RPMs. The RPMs
-are the same RPMs included in the ISO and include all the necessary disk
-images and configuration files to execute an OPNFV deployment. Either method
-will prepare a host to the same ready state for OPNFV deployment.
+skip the ISO step and simply install the (``python34-opnfv-apex*.rpm``) RPM.
``opnfv-deploy`` instantiates a Triple-O Undercloud VM server using libvirt
as its provider. This VM is then configured and used to provision the
-OPNFV target deployment (3 controllers, n compute nodes). These nodes can
-be either virtual or bare metal. This guide contains instructions for
-installing either method.
+OPNFV target deployment. These nodes can be either virtual or bare metal.
+This guide contains instructions for installing either method.
diff --git a/docs/release/installation/references.rst b/docs/release/installation/references.rst
index 249da22..b8b177d 100644
--- a/docs/release/installation/references.rst
+++ b/docs/release/installation/references.rst
@@ -21,7 +21,7 @@ OPNFV
OpenStack
---------
-`OpenStack Newton Release artifacts <http://www.openstack.org/software/newton>`_
+`OpenStack Queens Release artifacts <http://www.openstack.org/software/queens>`_
`OpenStack documentation <http://docs.openstack.org>`_
@@ -30,7 +30,7 @@ OpenDaylight
Upstream OpenDaylight provides `a number of packaging and deployment options <https://wiki.opendaylight.org/view/Deployment>`_ meant for consumption by downstream projects like OPNFV.
-Currently, OPNFV Apex uses `OpenDaylight's Puppet module <https://github.com/dfarrell07/puppet-opendaylight>`_, which in turn depends on `OpenDaylight's RPM <http://cbs.centos.org/repos/nfv7-opendaylight-4-release/>`_.
+Currently, OPNFV Apex uses `OpenDaylight's Puppet module <https://git.opendaylight.org/gerrit/#/admin/projects/integration/packaging/puppet-opendaylight>`_, which in turn depends on `OpenDaylight's RPM <https://nexus.opendaylight.org/content/repositories/opendaylight-nitrogen-epel-7-x86_64-devel/>`_.
RDO Project
-----------
diff --git a/docs/release/installation/requirements.rst b/docs/release/installation/requirements.rst
index 8d44140..239db19 100644
--- a/docs/release/installation/requirements.rst
+++ b/docs/release/installation/requirements.rst
@@ -6,7 +6,7 @@ Jump Host Requirements
The Jump Host requirements are outlined below:
-1. CentOS 7 (from ISO or self-installed).
+1. CentOS 7 (self-installed) or Fedora (with Snapshot deployment).
2. Root access.
@@ -15,7 +15,7 @@ The Jump Host requirements are outlined below:
4. minimum 1 networks and maximum 5 networks, multiple NIC and/or VLAN
combinations are supported. This is virtualized for a VM deployment.
-5. The Euphrates Apex RPMs and their dependencies.
+5. The Gambia Apex RPM and its dependencies.
6. 16 GB of RAM for a bare metal deployment, 64 GB of RAM for a Virtual
Deployment.
diff --git a/docs/release/installation/troubleshooting.rst b/docs/release/installation/troubleshooting.rst
index 6a81bef..f5b4208 100644
--- a/docs/release/installation/troubleshooting.rst
+++ b/docs/release/installation/troubleshooting.rst
@@ -132,3 +132,13 @@ some possible solutions or workarounds to get the process continued.
it will pass a different value for step each time. There is a total of
five steps. Some of these steps will not be executed depending on the
type of scenario that is being deployed.
+
+Reporting a Bug
+---------------
+
+Please report bugs via the `OPNFV Apex JIRA <https://wiki.opnfv.org/apex>`_
+page. You may now use the log collecting utility provided by Apex in order
+to gather all of the logs from the overcloud after a deployment failure. To
+do this please use the ``opnfv-pyutil --fetch-logs`` command. The log file
+location will be displayed at the end of executing the script. Please attach
+this log to the JIRA Bug.
diff --git a/docs/release/installation/upstream.rst b/docs/release/installation/upstream.rst
new file mode 100644
index 0000000..f18c4b1
--- /dev/null
+++ b/docs/release/installation/upstream.rst
@@ -0,0 +1,101 @@
+Deploying Directly from Upstream
+================================
+
+When installing the Undercloud and Overcloud, the disk images are now downloaded
+directly from upstream artifacts. Essentially this deployment pulls the latest
+RDO overcloud and undercloud artifacts at deploy time. This option is useful
+for being able to pull the latest Queens and other OPNFV components which have
+been promoted via a TripleO pipeline and deemed to be stable.
+
+Upstream Deployment Key Features
+--------------------------------
+
+In addition to being able to install newer versions of OpenStack, the upstream
+deployment option allows the use of a newer version of TripleO, which provides
+overcloud container support. Therefore when deploying from upstream with an
+OpenStack version newer than Pike, every OpenStack service (also OpenDaylight)
+will be running as a docker container. Furthermore, deploying upstream gives
+the user the flexibility of including any upstream OpenStack patches he/she
+may need by simply adding them into the deploy settings file. The patches will
+be applied live during deployment.
+
+Installation Guide - Upstream Deployment
+========================================
+
+This section goes step-by-step on how to correctly install and provision the
+OPNFV target system using a direct upstream deployment.
+
+Special Requirements for Upstream Deployments
+---------------------------------------------
+
+With upstream deployments it is required to have internet access. In addition,
+the upstream artifacts will be cached under the root partition of the jump
+host. It is required to at least have 10GB free space in the root partition
+in order to download and prepare the cached artifacts.
+
+Scenarios and Deploy Settings for Upstream Deployments
+------------------------------------------------------
+
+The deploy settings and scenarios included with the Gambia release of Apex will
+be supported as deemed by the `OPNFV Scenarios in Apex`_ section of this guide.
+Each of these scenarios has been tested by Apex over the Gambia release, and
+using those deploy settings will control which upstream artifacts are pulled
+at deploy time. By specifying different versions of OpenStack, ODL, or other
+components in the deploy settings, different upstream artifacts may be downloaded
+and are not considered to be supported. For deploying newer versions of components
+it is advised to use the master branch of OPNFV Apex as part of our continuous
+integration effort to support those components.
+
+Including Upstream Patches with Deployment
+------------------------------------------------------
+
+With upstream deployments it is possible to include any pending patch in
+OpenStack gerrit with the deployment. These patches are applicable to either
+the undercloud or the overcloud. This feature is useful in the case where
+a developer or user desires to pull in an unmerged patch for testing with a
+deployment. In order to use this feature, include the following in the deploy
+settings file, under "global_params" section:
+
+.. code-block:: yaml
+
+ patches:
+ undercloud:
+ - change-id: <gerrit change id>
+ project: openstack/<project name>
+ branch: <branch where commit is proposed>
+ overcloud:
+ - change-id: <gerrit change id>
+ project: openstack/<project name>
+ branch: <branch where commit is proposed>
+
+You may include as many patches as needed. If the patch is already merged or
+abandoned, then it will not be included in the deployment.
+
+Running ``opnfv-deploy``
+------------------------
+
+Deploying is similar to the typical method used for baremetal and virtual
+deployments with the addition of a few new arguments to the ``opnfv-deploy``
+command. The artifacts for each upstream deployment are only
+downloaded when a newer version is detected upstream. In order to explicitly
+disable downloading new artifacts from upstream if previous artifacts are
+already cached, please use the ``--no-fetch`` argument.
+
+Interacting with Containerized Overcloud
+----------------------------------------
+
+Upstream deployments will use a containerized overcloud. These containers are
+Docker images built by the Kolla project. The Containers themselves are run
+and controlled through Docker as root user. In order to access logs for each
+service, examine the '/var/log/containers' directory or use the `docker logs
+<container name>`. To see a list of services running on the node, use the
+``docker ps`` command. Each container uses host networking, which means that
+the networking of the overcloud node will act the same exact way as a
+traditional deployment. In order to attach to a container, use this command:
+``docker exec -it <container name/id> bin/bash``. This will login to the
+container with a bash shell. Note the containers do not use systemd, unlike
+the traditional deployment model and are instead started as the first process
+in the container. To restart a service, use the ``docker restart <container>``
+command.
+
+.. _`OPNFV Scenarios in Apex`: architecture.html#opnfv-scenarios-in-apex
diff --git a/docs/release/installation/virtual.rst b/docs/release/installation/virtual.rst
index 9336b8e..a844d43 100644
--- a/docs/release/installation/virtual.rst
+++ b/docs/release/installation/virtual.rst
@@ -3,20 +3,36 @@ 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.
``opnfv-deploy`` still deploys an undercloud VM. In addition to the undercloud
VM a collection of VMs (3 control nodes + 2 compute for an HA deployment or 1
-control node and 1 or more compute nodes for a Non-HA Deployment) will be
+control node and 0 or more compute nodes for a Non-HA Deployment) will be
defined for the target OPNFV deployment. All overcloud VMs are registered
with a Virtual BMC emulator which will service power management (IPMI)
commands. The overcloud VMs are still provisioned with the same disk images
-and configuration that baremetal would use.
+and configuration that baremetal would use. Using 0 nodes for a virtual
+deployment will automatically deploy "all-in-one" nodes which means the compute
+will run along side the controller in a single overcloud node. Specifying 3
+control nodes will result in a highly-available service model.
To Triple-O these nodes look like they have just built and registered the same
way as bare metal nodes, the main difference is the use of a libvirt driver for
@@ -24,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
=======================================
@@ -54,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
@@ -67,7 +100,7 @@ environment will deploy with the following architecture:
- 1 undercloud VM
- The option of 3 control and 2 or more compute VMs (HA Deploy / default)
- or 1 control and 1 or more compute VM (Non-HA deploy / pass -n)
+ or 1 control and 0 or more compute VMs (Non-HA deploy)
- 1-5 networks: provisioning, private tenant networking, external, storage
and internal API. The API, storage and tenant networking networks can be
@@ -80,10 +113,11 @@ Follow the steps below to execute:
-n network_settings.yaml -d deploy_settings.yaml``
Note it can also be useful to run the command with the ``--debug``
argument which will enable a root login on the overcloud nodes with
- password: 'opnfv-apex'. It is also useful in some cases to surround the
+ password: 'opnfvapex'. It is also useful in some cases to surround the
deploy command with ``nohup``. For example:
``nohup <deploy command> &``, will allow a deployment to continue even if
- ssh access to the Jump Host is lost during deployment.
+ ssh access to the Jump Host is lost during deployment. By specifying
+ ``--virtual-computes 0``, the deployment will proceed as all-in-one.
2. It will take approximately 45 minutes to an hour to stand up undercloud,
define the target virtual machines, configure the deployment and execute
@@ -92,11 +126,48 @@ 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
-------------------------
To verify the set you can follow the instructions in the `Verifying the Setup`_
section.
-.. _`Install Bare Metal Jump Host`: index.html#install-bare-metal-jump-host
-.. _`Verifying the Setup`: index.html#verifying-the-setup
+.. _`Install Bare Metal Jump Host`: baremetal.html#install-bare-metal-jump-host
+.. _`Verifying the Setup`: verification.html#verifying-the-setup