Updates docs and scenarios for Euphrates

Change-Id: I2da89d7a6ab4b0549edded908acc760b949231e1
Signed-off-by: Tim Rozet <trozet@redhat.com>

15 files changed, 337 insertions, 128 deletions

diff --git a/docs/release/installation/architecture.rst b/docs/release/installation/architecture.rst
index 5d019ed1..e2c0bb7e 100644
--- a/docs/release/installation/architecture.rst
+++ b/docs/release/installation/architecture.rst
@@ -16,7 +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 jumphost.  This VM is pre-built and distributed as part
+virtual machine on a Jump Host.  This VM is pre-built and distributed as part
 of the Apex RPM.
 
 The overcloud is OPNFV. Configuration will be passed into undercloud and
@@ -116,7 +116,7 @@ the installer as a (-d) deploy setting.  Read further in the Apex documentation
 to learn more about invoking the deploy command.  Below is quick reference
 matrix for OPNFV scenarios supported in Apex.  Please refer to the respective
 OPNFV Docs documentation for each scenario in order to see a full scenario
-description.  Also, please refer to release-notes for information about known
+description.  Also, please refer to release notes for information about known
 issues per scenario.  The following scenarios correspond to a supported
 <Scenario>.yaml deploy settings file:
 
@@ -127,17 +127,24 @@ issues per scenario.  The following scenarios correspond to a supported
 +-------------------------+-------------+---------------+
 | os-nosdn-nofeature-noha | Apex        | Yes           |
 +-------------------------+-------------+---------------+
-| os-nosdn-ovs_dpdk-ha    | OVS for NFV | Yes           |
+| os-nosdn-bar-ha         | Barometer   | Yes           |
 +-------------------------+-------------+---------------+
-| os-nosdn-ovs_dpdk-noha  | OVS for NFV | Yes           |
+| os-nosdn-bar-noha       | Barometer   | Yes           |
++-------------------------+-------------+---------------+
+| os-nosdn-calipso-noha   | Calipso     | Yes           |
++-------------------------+-------------+---------------+
+| os-nosdn-ovs_dpdk-ha    | Apex        | Yes           |
++-------------------------+-------------+---------------+
+| os-nosdn-ovs_dpdk-noha  | Apex        | Yes           |
 +-------------------------+-------------+---------------+
 | os-nosdn-fdio-ha        | FDS         | No            |
 +-------------------------+-------------+---------------+
 | os-nosdn-fdio-noha      | FDS         | No            |
 +-------------------------+-------------+---------------+
-| os-nosdn-kvm-ha         | KVM for NFV | Yes           |
+| os-nosdn-kvm_ovs_dpdk-ha| KVM for NFV | Yes           |
 +-------------------------+-------------+---------------+
-| os-nosdn-kvm-noha       | KVM for NFV | Yes           |
+| os-nosdn-kvm_ovs_dpdk   | KVM for NFV | Yes           |
+| -noha                   |             |               |
 +-------------------------+-------------+---------------+
 | os-nosdn-performance-ha | Apex        | Yes           |
 +-------------------------+-------------+---------------+
@@ -145,22 +152,30 @@ issues per scenario.  The following scenarios correspond to a supported
 +-------------------------+-------------+---------------+
 | os-odl-nofeature-noha   | Apex        | Yes           |
 +-------------------------+-------------+---------------+
-| os-odl-ovs_dpdk-ha      | OVS for NFV | Yes           |
+| os-odl-ovs_dpdk-ha      | Apex        | No            |
 +-------------------------+-------------+---------------+
-| os-odl-ovs_dpdk-noha    | OVS for NFV | Yes           |
+| os-odl-ovs_dpdk-noha    | Apex        | No            |
 +-------------------------+-------------+---------------+
 | os-odl-bgpvpn-ha        | SDNVPN      | Yes           |
 +-------------------------+-------------+---------------+
 | os-odl-bgpvpn-noha      | SDNVPN      | Yes           |
 +-------------------------+-------------+---------------+
-| os-odl-gluon-noha       | GluOn       | Yes           |
+| os-odl-sfc-ha           | SFC         | Yes           |
++-------------------------+-------------+---------------+
+| os-odl-sfc-noha         | SFC         | Yes           |
 +-------------------------+-------------+---------------+
-| os-odl-csit-noha        | Apex        | Yes           |
+| os-odl-gluon-noha       | Gluon       | No            |
++-------------------------+-------------+---------------+
+| os-odl-csit-noha        | Apex        | No            |
 +-------------------------+-------------+---------------+
 | os-odl-fdio-ha          | FDS         | Yes           |
 +-------------------------+-------------+---------------+
 | os-odl-fdio-noha        | FDS         | Yes           |
 +-------------------------+-------------+---------------+
+| os-odl-fdio_dvr-ha      | FDS         | No            |
++-------------------------+-------------+---------------+
+| os-odl-fdio_dvr-noha    | FDS         | No            |
++-------------------------+-------------+---------------+
 | os-onos-nofeature-ha    | ONOSFW      | No            |
 +-------------------------+-------------+---------------+
 | os-onos-sfc-ha          | ONOSFW      | No            |
diff --git a/docs/release/installation/baremetal.rst b/docs/release/installation/baremetal.rst
index c6ab9e82..f607107f 100644
--- a/docs/release/installation/baremetal.rst
+++ b/docs/release/installation/baremetal.rst
@@ -10,11 +10,11 @@ reference platform.  All the networks involved in the OPNFV infrastructure as
 well as the provider networks and the private tenant VLANs needs to be manually
 configured.
 
-The Jumphost can be installed using the bootable ISO or by using the
-(``opnfv-apex*.rpm``) RPMs and their dependencies.  The Jumphost should then be
-configured with an IP gateway on its admin or public interface and configured
-with a working DNS server.  The Jumphost should also have routable access
-to the lights out network for the overcloud nodes.
+The Jump Host can be installed using the bootable ISO or by using the
+(``opnfv-apex*.rpm``) RPMs and their dependencies.  The Jump Host should then
+be configured with an IP gateway on its admin or public interface and
+configured with a working DNS server.  The Jump Host should also have routable
+access to the lights out network for the overcloud nodes.
 
 ``opnfv-deploy`` is then executed in order to deploy the undercloud VM and to
 provision the overcloud nodes.  ``opnfv-deploy`` uses three configuration files
@@ -52,84 +52,58 @@ 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.
 
-Installation High-Level Overview - VM Deployment
-================================================
-
-The VM nodes 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
-defined for the target OPNFV deployment.  The part of the toolchain that
-executes IPMI power instructions calls into libvirt instead of the IPMI
-interfaces on baremetal servers to operate the power management.  These VMs are
-then provisioned with the same disk images and configuration that baremetal
-would be.
-
-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
-the power management.
-
 Installation Guide - Bare Metal Deployment
 ==========================================
 
 This section goes step-by-step on how to correctly install and provision the
 OPNFV target system to bare metal nodes.
 
-Install Bare Metal Jumphost
----------------------------
+Install Bare Metal Jump Host
+----------------------------
 
-1a. If your Jumphost 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
+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
     "Virtualization Host" install.  If you perform a "Minimal Install" or
     install type other than "Virtualization Host" simply run
-    ``sudo yum groupinstall "Virtualization Host"``
+    ``sudo yum -y groupinstall "Virtualization Host"``
     ``chkconfig libvirtd on && reboot``
-    to install virtualzation support and enable libvirt on boot. If you use the
-    CentOS 7 DVD proceed to step 1b once the CentOS 7 with "Virtualzation Host"
-    support is completed.
-
-1b. If your Jump host already has CentOS 7 with libvirt running on it then
-    install the RDO Newton Release RPM and epel-release:
-
-    ``sudo yum install https://repos.fedorapeople.org/repos/openstack/openstack-newton/rdo-release-newton-4.noarch.rpm``
-    ``sudo yum install epel-release``
-
-    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
-    use this repository you need to download the OpenVSwitch RPM from the RDO
-    Project repositories and install it with the opnfv-apex RPM.
+    to install virtualization support and enable libvirt on boot. If you use
+    the CentOS 7 DVD proceed to step 1b once the CentOS 7 with
+    "Virtualization Host" support is completed.
 
-2a. Boot the ISO off of a USB or other installation media and walk through
+1b. Boot the ISO off of a USB or other installation media and walk through
     installing OPNFV CentOS 7.  The ISO comes prepared to be written directly
     to a USB drive with dd as such:
 
     ``dd if=opnfv-apex.iso of=/dev/sdX bs=4M``
 
     Replace /dev/sdX with the device assigned to your usb drive. Then select
-    the USB device as the boot media on your Jumphost
-
-2b. If your Jump host already has CentOS 7 with libvirt running on it then
-    install the opnfv-apex RPMs using the OPNFV artifacts yum repo. This yum
-    repo is created at release. It will not exist before release day.
+    the USB device as the boot media on your Jump Host
 
-    ``sudo yum install http://artifacts.opnfv.org/apex/euphrates/opnfv-apex-release-euphrates.noarch.rpm``
+2a. When not using the OPNFV Apex ISO, install these repos:
 
-    Once you have installed the repo definitions for Apex, RDO and EPEL then
-    yum install Apex:
+    ``sudo yum install https://repos.fedorapeople.org/repos/openstack/openstack-ocata/rdo-release-ocata-3.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 yum install opnfv-apex``
+    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
+    use this repository you need to download the OpenVSwitch RPM from the RDO
+    Project repositories and install it with the opnfv-apex RPM.  The
+    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.
 
-2c. If you choose not to use the Apex yum repo or you choose to use
-    pre-released RPMs you can download and install the required RPMs from the
-    artifacts site <http://artifacts.opnfv.org/apex.html>. The following RPMs
-    are available for installation:
+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``.
+    The following RPMs are available for installation:
 
-    - opnfv-apex                 - OpenDaylight, OVN, and nosdn support *
+    - 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 **
@@ -141,31 +115,20 @@ Install Bare Metal Jumphost
     - python34-cryptography      - (reqed) Dependency of python34-opnfv-apex **
     - python34-libvirt           - (reqed) Dependency of python34-opnfv-apex **
 
-    \* One or more of these RPMs is required
-    Only one of opnfv-apex or opnfv-apex-onos is required. It is safe to leave
-    the unneeded SDN controller's RPMs uninstalled if you do not intend to use
-    them.
-
     ** These RPMs are not yet distributed by CentOS or EPEL.
     Apex has built these for distribution with Apex while CentOS and EPEL do
     not distribute them. Once they are carried in an upstream channel Apex will
     no longer carry them and they will not need special handling for
-    installation.
-
-
-    The EPEL and RDO yum repos are still required:
-    ``sudo yum install epel-release``
-    ``sudo yum install https://repos.fedorapeople.org/repos/openstack/openstack-newton/rdo-release-newton-4.noarch.rpm``
+    installation.  You do not need to explicitly install these as they will be
+    automatically installed by installing python34-opnfv-apex when the
+    opnfv-apex.repo has been previously downloaded to ``/etc/yum.repos.d/``.
 
-    Once the apex RPMs are downloaded install them by passing the file names
-    directly to yum:
-    ``sudo yum install python34-markupsafe-<version>.rpm
-    python3-jinja2-<version>.rpm python3-ipmi-<version>.rpm``
-    ``sudo yum install opnfv-apex-<version>.rpm
-    opnfv-apex-undercloud-<version>.rpm python34-opnfv-apex-<version>.rpm``
+    Install the three required RPMs (replace <rpm> with the actual downloaded
+    artifact):
+    ``yum -y install <opnfv-apex.rpm> <opnfv-apex-undercloud> <python34-opnfv-apex>``
 
 3.  After the operating system and the opnfv-apex RPMs are installed, login to
-    your Jumphost as root.
+    your Jump Host as root.
 
 4.  Configure IP addresses on the interfaces that you have selected as your
     networks.
@@ -259,6 +222,12 @@ Follow the steps below to execute:
     If you need more information about the options that can be passed to
     opnfv-deploy use ``opnfv-deploy --help``.  -n
     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
+    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.
 
 2.  Wait while deployment is executed.
     If something goes wrong during this part of the process, start by reviewing
@@ -266,7 +235,7 @@ Follow the steps below to execute:
     uncommon for something small to be overlooked or mis-typed.
     You will also notice outputs in your shell as the deployment progresses.
 
-3.  When the deployment is complete the undercloud IP and ovecloud dashboard
+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
diff --git a/docs/release/installation/index.rst b/docs/release/installation/index.rst
index 9ac4c225..8fb49464 100644
--- a/docs/release/installation/index.rst
+++ b/docs/release/installation/index.rst
@@ -15,7 +15,7 @@ Contents:
    architecture.rst
    requirements.rst
    baremetal.rst
-   virtualinstall.rst
+   virtual.rst
    verification.rst
    troubleshooting.rst
    references.rst
diff --git a/docs/release/installation/introduction.rst b/docs/release/installation/introduction.rst
index 0e376189..bb220b7d 100644
--- a/docs/release/installation/introduction.rst
+++ b/docs/release/installation/introduction.rst
@@ -26,10 +26,10 @@ CentOS 7 libvirt enabled host. The RPM contains a collection of
 configuration files, prebuilt disk images, and the automatic deployment
 script (``opnfv-deploy``).
 
-An OPNFV install requires a "Jumphost" in order to operate.  The bootable
-ISO will allow you to install a customized CentOS 7 release to the Jumphost,
+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,
 which includes the required packages needed to run ``opnfv-deploy``.
-If you already have a Jumphost with CentOS 7 installed, you may choose to
+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
diff --git a/docs/release/installation/references.rst b/docs/release/installation/references.rst
index b777bac5..249da226 100644
--- a/docs/release/installation/references.rst
+++ b/docs/release/installation/references.rst
@@ -16,7 +16,7 @@ OPNFV
 
 `OPNFV Apex project page <https://wiki.opnfv.org/apex>`_
 
-:ref:`OPNFV Apex Release Notes <apex-releasenotes>`
+:ref:`OPNFV Apex Release Notes <apex-release-notes>`
 
 OpenStack
 ---------
diff --git a/docs/release/installation/requirements.rst b/docs/release/installation/requirements.rst
index 9c892a3d..8d441404 100644
--- a/docs/release/installation/requirements.rst
+++ b/docs/release/installation/requirements.rst
@@ -1,10 +1,10 @@
 Setup Requirements
 ==================
 
-Jumphost Requirements
+Jump Host Requirements
 ---------------------
 
-The Jumphost requirements are outlined below:
+The Jump Host requirements are outlined below:
 
 1.     CentOS 7 (from ISO or self-installed).
 
@@ -17,8 +17,8 @@ The Jumphost requirements are outlined below:
 
 5.     The Euphrates Apex RPMs and their dependencies.
 
-6.     16 GB of RAM for a bare metal deployment, 64 GB of RAM for a VM
-       deployment.
+6.     16 GB of RAM for a bare metal deployment, 64 GB of RAM for a Virtual
+       Deployment.
 
 Network Requirements
 --------------------
@@ -27,7 +27,7 @@ Network requirements include:
 
 1.     No DHCP or TFTP server running on networks used by OPNFV.
 
-2.     1-5 separate networks with connectivity between Jumphost and nodes.
+2.     1-5 separate networks with connectivity between Jump Host and nodes.
 
        -  Control Plane (Provisioning)
 
@@ -39,7 +39,7 @@ Network requirements include:
 
        -  Internal API Network* (required for IPv6 \*\*)
 
-3.     Lights out OOB network access from Jumphost with IPMI node enabled
+3.     Lights out OOB network access from Jump Host with IPMI node enabled
        (bare metal deployment only).
 
 4.     External network is a routable network from outside the cloud,
diff --git a/docs/release/installation/troubleshooting.rst b/docs/release/installation/troubleshooting.rst
index efff9796..6a81bef6 100644
--- a/docs/release/installation/troubleshooting.rst
+++ b/docs/release/installation/troubleshooting.rst
@@ -5,7 +5,7 @@ This section aims to explain in more detail the steps that Apex follows
 to make a deployment. It also tries to explain possible issues you might find
 in the process of building or deploying an environment.
 
-After installing the Apex RPMs in the jumphost, some files will be located
+After installing the Apex RPMs in the Jump Host, some files will be located
 around the system.
 
 1.  /etc/opnfv-apex: this directory contains a bunch of scenarios to be
@@ -17,13 +17,10 @@ around the system.
 2.  /usr/bin/: it contains the binaries for the commands opnfv-deploy,
     opnfv-clean and opnfv-util.
 
-3.  /var/opt/opnfv/: it contains several files and directories.
+3.  /usr/share/opnfv/: contains Ansible playbooks and other non-python based
+    configuration and libraries.
 
-   3.1.   images/: this folder contains the images that will be deployed
-   according to the chosen scenario.
-
-   3.2.   lib/: bunch of scripts that will be executed in the different phases
-   of deployment.
+4.  /var/opt/opnfv/: contains disk images for Undercloud and Overcloud
 
 
 Utilization of Images
diff --git a/docs/release/installation/verification.rst b/docs/release/installation/verification.rst
index 5156effc..fa60ca32 100644
--- a/docs/release/installation/verification.rst
+++ b/docs/release/installation/verification.rst
@@ -2,9 +2,9 @@ Verifying the Setup
 -------------------
 
 Once the deployment has finished, the OPNFV deployment can be accessed via the
-undercloud node. From the jump host ssh to the undercloud host and become the
-stack user. Alternativly ssh keys have been setup such that the root user on
-the jump host can ssh to undercloud directly as the stack user. For
+undercloud node. From the Jump Host ssh to the undercloud host and become the
+stack user. Alternatively ssh keys have been setup such that the root user on
+the Jump Host can ssh to undercloud directly as the stack user. For
 convenience a utility script has been provided to look up the undercloud's ip
 address and ssh to the undercloud all in one command. An optional user name can
 be passed to indicate whether to connect as the stack or root user. The stack
@@ -21,7 +21,7 @@ appropriate RC file to interact with the respective OpenStack deployment.
 | ``source overcloudrc`` (overcloud / OPNFV)
 
 The contents of these files include the credentials for the administrative user
-for undercloud and OPNFV respectivly. At this point both undercloud and OPNFV
+for undercloud and OPNFV respectively. At this point both undercloud and OPNFV
 can be interacted with just as any OpenStack installation can be. Start by
 listing the nodes in the undercloud that were used to deploy the overcloud.
 
diff --git a/docs/release/installation/virtualinstall.rst b/docs/release/installation/virtual.rst
index 61fc4be6..9336b8e7 100644
--- a/docs/release/installation/virtualinstall.rst
+++ b/docs/release/installation/virtual.rst
@@ -1,20 +1,28 @@
 Installation High-Level Overview - Virtual Deployment
 =====================================================
 
-The VM nodes deployment operates almost the same way as the bare metal
-deployment with a few differences.  ``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 defined for the target
-OPNFV deployment.  The part of the toolchain that executes IPMI power
-instructions calls into libvirt instead of the IPMI interfaces on baremetal
-servers to operate the power management.  These VMs are then provisioned with
-the same disk images and configuration that baremetal would be. 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 the power
-management.  Finally, the default network_settings file will deploy without
+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.
+
+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
+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.
+
+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
+the power management.  Finally, the default network settings file will deploy without
 modification.  Customizations are welcome but not needed if a generic set of
-network_settings are acceptable.
+network settings are acceptable.
 
 Installation Guide - Virtual Deployment
 =======================================
@@ -41,10 +49,10 @@ Virtualization is enabled in BIOS, and that the output of ``cat
 ``lsmod`` that the kvm_intel module is loaded for x86_64 machines, and
 kvm_amd is loaded for AMD64 machines.
 
-Install Jumphost
-----------------
+Install Jump Host
+-----------------
 
-Follow the instructions in the `Install Bare Metal Jumphost`_ section.
+Follow the instructions in the `Install Bare Metal Jump Host`_ section.
 
 Running ``opnfv-deploy``
 ------------------------
@@ -70,6 +78,12 @@ Follow the steps below to execute:
 1.  ``sudo opnfv-deploy -v [ --virtual-computes n ]
     [ --virtual-cpus n ] [ --virtual-ram n ]
     -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
+    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.
 
 2.  It will take approximately 45 minutes to an hour to stand up undercloud,
     define the target virtual machines, configure the deployment and execute
@@ -84,5 +98,5 @@ Verifying the Setup - VMs
 To verify the set you can follow the instructions in the `Verifying the Setup`_
 section.
 
-.. _`Install Bare Metal Jumphost`: index.html#install-bare-metal-jumphost
+.. _`Install Bare Metal Jump Host`: index.html#install-bare-metal-jump-host
 .. _`Verifying the Setup`: index.html#verifying-the-setup
diff --git a/docs/release/release-notes/index.rst b/docs/release/release-notes/index.rst
index 3fe94631..a87e2612 100644
--- a/docs/release/release-notes/index.rst
+++ b/docs/release/release-notes/index.rst
@@ -1,4 +1,4 @@
-.. _apex-releasenotes:
+.. _apex-release-notes:
 
 ************************
 OPNFV Apex Release Notes
diff --git a/docs/release/release-notes/release-notes.rst b/docs/release/release-notes/release-notes.rst
index d6785791..a2369e38 100644
--- a/docs/release/release-notes/release-notes.rst
+++ b/docs/release/release-notes/release-notes.rst
@@ -67,7 +67,7 @@ Euphrates.  Ceph is setup as 3 OSDs and 3 Monitors, one OSD+Mon per Controller
 node in an HA setup.  Apex also supports non-HA deployments, which deploys a
 single controller and n number of compute nodes.  Furthermore, Apex is
 capable of deploying scenarios in a bare metal or virtual fashion.  Virtual
-deployments use multiple VMs on the jump host and internal networking to
+deployments use multiple VMs on the Jump Host and internal networking to
 simulate the a bare metal deployment.
 
 - Documentation is built by Jenkins
@@ -267,7 +267,7 @@ System Limitations
 
 **Storage:**    Ceph is the only supported storage configuration.
 
-**Min master requirements:** At least 16GB of RAM for baremetal jumphost,
+**Min master requirements:** At least 16GB of RAM for baremetal Jump Host,
 24GB for virtual deployments (noHA).
 
 
diff --git a/docs/release/scenarios/os-nosdn-ovs_dpdk-ha/index.rst b/docs/release/scenarios/os-nosdn-ovs_dpdk-ha/index.rst
new file mode 100644
index 00000000..febf16c1
--- /dev/null
+++ b/docs/release/scenarios/os-nosdn-ovs_dpdk-ha/index.rst
@@ -0,0 +1,16 @@
+.. _os-nosdn-ovs_dpdk-ha:
+
+.. OPNFV - Open Platform for Network Function Virtualization
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+
+**********************************************************************************
+User Space Accelerated OVS scenario: os-nosdn-ovs_dpdk-ha Overview and Description
+**********************************************************************************
+
+.. toctree::
+   :numbered:
+   :maxdepth: 4
+
+   os-nosdn-ovs_dpdk-ha.rst
diff --git a/docs/release/scenarios/os-nosdn-ovs_dpdk-ha/os-nosdn-ovs_dpdk-ha.rst b/docs/release/scenarios/os-nosdn-ovs_dpdk-ha/os-nosdn-ovs_dpdk-ha.rst
new file mode 100644
index 00000000..cc5fee3b
--- /dev/null
+++ b/docs/release/scenarios/os-nosdn-ovs_dpdk-ha/os-nosdn-ovs_dpdk-ha.rst
@@ -0,0 +1,91 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) <optionally add copywriters name>
+
+This document provides scenario level details for Euphrates 1.0 of
+deployment with no SDN controller and DPDK enabled Open vSwitch.
+
+.. contents::
+   :depth: 3
+   :local:
+
+Introduction
+============
+
+NFV and virtualized high performance applications, such as video processing,
+require Open vSwitch to be accelerated with a fast data plane solution that
+provides both carrier grade forwarding performance, scalability and open
+extensibility.
+
+A key component of any NFV solution is the virtual forwarder, which should
+consist of soft switch that includes an accelerated data plane component. For
+this, any virtual switch should make use of hardware accelerators and optimized
+cache operation to be run in user space.
+
+Scenario components and composition
+===================================
+
+This scenario enables high performance data plan acceleration by utilizing
+DPDK enabled Open vSwitch (OVS).  This allows packet switching to be isolated
+to particular hardware resources (CPUs, huge page memory allocation) without
+kernel interrupt or context switching on the data plane CPU.
+
+Tenant networking leverages Open vSwitch accelerated with a fast user space
+data path such.  OVS with the Linux kernel module data path is used for all
+other connectivity, such as connectivity to the external network (i.e. br-ex)
+is performed via non-accelerated OVS.
+
+Scenario Configuration
+======================
+
+Due to the performance optimization done by this scenario, it is recommended to
+set some performance settings in the deploy settings in order to ensure maximum
+performance.  This is not necessary unless doing a baremetal deployment.  Note,
+this scenario requires taking the NIC mapped to the tenant network on the
+compute node and binding it to DPDK.  This means it will no longer be
+accessible via the kernel.  Ensure the NIC that is mapped to the Compute
+Tenant network supports DPDK.
+
+Make a copy of the deploy settings file, os-nosdn-ovs_dpdk-ha.yaml.  Under the
+kernel options for Compute, edit as follows:
+ - hugepagesz: the size of hugepages as an integer, followed by unit M
+   (megabyte) or G (gigabyte).
+ - hugepages: number of hugepages of hugepagesz size.  Huge page memory will be
+   used for OVS as well as each nova instance spawned.  It is a good idea to
+   allocate the maximum number possible, while still leaving some non-huge page
+   memory available to other processes (nova-compute, etc).
+ - isolcpus: comma-separated list of CPUs to isolate from the kernel.  Isolated
+   CPUs will be used for pinning OVS and libvirtd to.
+
+Under the performance->Compute->ovs section, edit as follows:
+ - socket_memory: the amount of huge page memory in MB to allocate to allocate
+   per socket to OVS as a comma-separated list.  It is best to allocate the
+   memory to the socket which is closest to the PCI-Express bus of the NIC
+   to be used with OVS DPDK for tenant traffic.
+ - pmd_cores: comma-separated list of cores to pin to the poll-mode driver in
+   OVS.  OVS DPDK will spawn TX/RX PMD threads to handle forwarding packets.
+   This setting identifies which cores to pin these threads to.  For best
+   performance, dedicate at least 2 isolated cores on the same NUMA node where
+   socket_memory was assigned.
+ - dpdk_cores: comma-separated list of cores to pin OVS lcore threads to.
+   These threads do validation and control handling and it may not have any
+   impact on performance to include this setting.
+
+Under the performance->Compute section.  Add a nova subsection and include
+the following setting:
+ - libvirtpin: comma-separated list of CPUs to pin libvirt (nova) instances to.
+   For best results, set this to be one or more CPUs that are located on the
+   same NUMA node where OVS socket memory was dedicated.
+
+Now deploy with the modified deploy settings file.
+
+Limitations, Issues and Workarounds
+===================================
+
+* _APEX-415 br-phy dpdk interfaces are not brought up by os-net-config
+
+References
+==========
+
+For more information on the OPNFV Euphrates release, please visit
+http://www.opnfv.org/euphrates
diff --git a/docs/release/scenarios/os-nosdn-ovs_dpdk-noha/index.rst b/docs/release/scenarios/os-nosdn-ovs_dpdk-noha/index.rst
new file mode 100644
index 00000000..699f3915
--- /dev/null
+++ b/docs/release/scenarios/os-nosdn-ovs_dpdk-noha/index.rst
@@ -0,0 +1,16 @@
+.. _os-nosdn-ovs_dpdk-noha:
+
+.. OPNFV - Open Platform for Network Function Virtualization
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+
+************************************************************************************
+User Space Accelerated OVS scenario: os-nosdn-ovs_dpdk-noha Overview and Description
+************************************************************************************
+
+.. toctree::
+   :numbered:
+   :maxdepth: 4
+
+   os-nosdn-ovs_dpdk-noha.rst
diff --git a/docs/release/scenarios/os-nosdn-ovs_dpdk-noha/os-nosdn-ovs_dpdk-noha.rst b/docs/release/scenarios/os-nosdn-ovs_dpdk-noha/os-nosdn-ovs_dpdk-noha.rst
new file mode 100644
index 00000000..b85f6e2b
--- /dev/null
+++ b/docs/release/scenarios/os-nosdn-ovs_dpdk-noha/os-nosdn-ovs_dpdk-noha.rst
@@ -0,0 +1,91 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) <optionally add copywriters name>
+
+This document provides scenario level details for Euphrates 1.0 of
+deployment with no SDN controller and DPDK enabled Open vSwitch.
+
+.. contents::
+   :depth: 3
+   :local:
+
+Introduction
+============
+
+NFV and virtualized high performance applications, such as video processing,
+require Open vSwitch to be accelerated with a fast data plane solution that
+provides both carrier grade forwarding performance, scalability and open
+extensibility.
+
+A key component of any NFV solution is the virtual forwarder, which should
+consist of soft switch that includes an accelerated data plane component. For
+this, any virtual switch should make use of hardware accelerators and optimized
+cache operation to be run in user space.
+
+Scenario components and composition
+===================================
+
+This scenario enables high performance data plan acceleration by utilizing
+DPDK enabled Open vSwitch (OVS).  This allows packet switching to be isolated
+to particular hardware resources (CPUs, huge page memory allocation) without
+kernel interrupt or context switching on the data plane CPU.
+
+Tenant networking leverages Open vSwitch accelerated with a fast user space
+data path such.  OVS with the Linux kernel module data path is used for all
+other connectivity, such as connectivity to the external network (i.e. br-ex)
+is performed via non-accelerated OVS.
+
+Scenario Configuration
+======================
+
+Due to the performance optimization done by this scenario, it is recommended to
+set some performance settings in the deploy settings in order to ensure maximum
+performance.  This is not necessary unless doing a baremetal deployment.  Note,
+this scenario requires taking the NIC mapped to the tenant network on the
+compute node and binding it to DPDK.  This means it will no longer be
+accessible via the kernel.  Ensure the NIC that is mapped to the Compute
+Tenant network supports DPDK.
+
+Make a copy of the deploy settings file, os-nosdn-ovs_dpdk-noha.yaml.  Under
+the kernel options for Compute, edit as follows:
+ - hugepagesz: the size of hugepages as an integer, followed by unit M
+   (megabyte) or G (gigabyte).
+ - hugepages: number of hugepages of hugepagesz size.  Huge page memory will be
+   used for OVS as well as each nova instance spawned.  It is a good idea to
+   allocate the maximum number possible, while still leaving some non-huge page
+   memory available to other processes (nova-compute, etc).
+ - isolcpus: comma-separated list of CPUs to isolate from the kernel.  Isolated
+   CPUs will be used for pinning OVS and libvirtd to.
+
+Under the performance->Compute->ovs section, edit as follows:
+ - socket_memory: the amount of huge page memory in MB to allocate to allocate
+   per socket to OVS as a comma-separated list.  It is best to allocate the
+   memory to the socket which is closest to the PCI-Express bus of the NIC
+   to be used with OVS DPDK for tenant traffic.
+ - pmd_cores: comma-separated list of cores to pin to the poll-mode driver in
+   OVS.  OVS DPDK will spawn TX/RX PMD threads to handle forwarding packets.
+   This setting identifies which cores to pin these threads to.  For best
+   performance, dedicate at least 2 isolated cores on the same NUMA node where
+   socket_memory was assigned.
+ - dpdk_cores: comma-separated list of cores to pin OVS lcore threads to.
+   These threads do validation and control handling and it may not have any
+   impact on performance to include this setting.
+
+Under the performance->Compute section.  Add a nova subsection and include
+the following setting:
+ - libvirtpin: comma-separated list of CPUs to pin libvirt (nova) instances to.
+   For best results, set this to be one or more CPUs that are located on the
+   same NUMA node where OVS socket memory was dedicated.
+
+Now deploy with the modified deploy settings file.
+
+Limitations, Issues and Workarounds
+===================================
+
+* _APEX-415 br-phy dpdk interfaces are not brought up by os-net-config
+
+References
+==========
+
+For more information on the OPNFV Euphrates release, please visit
+http://www.opnfv.org/euphrates