summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/conf.py1
-rw-r--r--docs/conf.yaml3
-rw-r--r--docs/contributor/APEX-on-aarch64.rst146
-rw-r--r--docs/contributor/upstream-overcloud-container-design.rst126
-rw-r--r--docs/index.rst23
-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
-rw-r--r--docs/release/release-notes/release-notes.rst191
-rw-r--r--docs/release/scenarios/k8s-nosdn-nofeature-noha/index.rst (renamed from docs/release/scenarios/os-nosdn-performance-ha/index.rst)10
-rw-r--r--docs/release/scenarios/k8s-nosdn-nofeature-noha/k8s-nosdn-nofeature-noha.rst46
-rw-r--r--docs/release/scenarios/os-nosdn-nofeature-ha/os-nosdn-nofeature-ha.rst8
-rw-r--r--docs/release/scenarios/os-nosdn-nofeature-noha/os-nosdn-nofeature-noha.rst8
-rw-r--r--docs/release/scenarios/os-nosdn-ovs_dpdk-ha/index.rst16
-rw-r--r--docs/release/scenarios/os-nosdn-ovs_dpdk-ha/os-nosdn-ovs_dpdk-ha.rst87
-rw-r--r--docs/release/scenarios/os-nosdn-ovs_dpdk-noha/index.rst16
-rw-r--r--docs/release/scenarios/os-nosdn-ovs_dpdk-noha/os-nosdn-ovs_dpdk-noha.rst87
-rw-r--r--docs/release/scenarios/os-nosdn-performance-ha/os-nosdn-performance-ha.rst54
-rw-r--r--docs/release/scenarios/os-odl-csit-noha/index.rst15
-rw-r--r--docs/release/scenarios/os-odl-csit-noha/os-odl-csit-noha.rst54
-rw-r--r--docs/release/scenarios/os-odl-nofeature-ha/os-odl-nofeature-ha.rst16
-rw-r--r--docs/release/scenarios/os-odl-nofeature-noha/os-odl-nofeature-noha.rst16
-rw-r--r--docs/release/scenarios/os-ovn-nofeature-ha/index.rst (renamed from docs/release/scenarios/os-ovn-nofeature-noha/index.rst)4
-rw-r--r--docs/release/scenarios/os-ovn-nofeature-ha/os-ovn-nofeature-ha.rst (renamed from docs/release/scenarios/os-ovn-nofeature-noha/os-ovn-nofeature-noha.rst)13
-rw-r--r--docs/requirements.txt2
32 files changed, 671 insertions, 616 deletions
diff --git a/docs/conf.py b/docs/conf.py
new file mode 100644
index 0000000..eb12e74
--- /dev/null
+++ b/docs/conf.py
@@ -0,0 +1 @@
+from docs_conf.conf import * # noqa: F401,F403
diff --git a/docs/conf.yaml b/docs/conf.yaml
new file mode 100644
index 0000000..6c76e3c
--- /dev/null
+++ b/docs/conf.yaml
@@ -0,0 +1,3 @@
+---
+project_cfg: opnfv
+project: APEX
diff --git a/docs/contributor/APEX-on-aarch64.rst b/docs/contributor/APEX-on-aarch64.rst
new file mode 100644
index 0000000..a2e90dd
--- /dev/null
+++ b/docs/contributor/APEX-on-aarch64.rst
@@ -0,0 +1,146 @@
+==================================================================================
+APEX on AARCH64
+==================================================================================
+
+This document describes the changes needed to deploy OPNFV-APEX on aarch64
+ * General considerations
+ * Creating undercloud and overcloud images using DIB
+ * Creating Kolla containers
+
+General considerations
+--------------------------
+
+OPNFV - APEX relies on artifacts created by the OOO project.
+
+Those artifacts are:
+
+1. Openstack packages, found in delorean_.
+
+ .. _delorean: http://www.python.org/
+
+2. UC and OC images created by RDO and found in images_.
+
+ .. _images: https://images.rdoproject.org/master/rdo_trunk/current-tripleo-rdo-internal/
+
+3. The containerized version of the openstack services found in docker.io_.
+
+ .. _docker.io: https://hub.docker.com/r/tripleomaster/
+
+All the above artifacts are x86_64 only and as a result cannot be used by APEX on aarch64
+As a result the user needs to create the Images locally before attempting to deploy.
+The only supported scenario is 'os-nosdn-rocky-ha'.
+
+Other than the aarch64 disk images and containers, there is no other special configuration
+required for aarch64. The only requirement is for the nodes to be identified as aarch64 nodes
+in the inventory files.
+
+For example :
+
+.. code-block:: yaml
+
+ node1:
+ mac_address: "68:05:CA:68:08:CA"
+ ipmi_ip: 10.10.10.10
+ ipmi_user: user
+ ipmi_pass: pass
+ pm_type: "pxe_ipmitool"
+ cpus: 1
+ memory: 128000
+ disk: 480
+ disk_device: sda
+ arch: "aarch64"
+ capabilities: "profile:control"
+
+
+Creating undercloud and overcloud images using DIB
+--------------------------------------------------
+In order to create that image DIB_ must be used. DIB can either be built from source or use yum to be installed.
+
+.. _DIB: https://github.com/openstack/diskimage-builder
+
+It is important to use a fairly late version of DIB to support UEFI systems. The version currently on epel does NOT have support for UEFI. The version on delorean (15.01) works just fine. DIB uses a YAML file from the user which describes how the
+image should look like. The original yaml from RDO is here_:
+
+
+.. _here: https://github.com/openstack/tripleo-common/blob/master/image-yaml/overcloud-images.yaml
+
+The equivelant yaml files for aarch64 are included in the apex repo in the "apex/contrib/aarch64" folder.
+The UC and OC images are very similar in terms of packages. The major difference is the partition table in EFI so for the undercloud, that has to provided as an environmental variable.
+
+.. code-block:: python
+
+ export DIB_BLOCK_DEVICE_CONFIG="
+
+ - local_loop:
+ name: image0
+
+ - partitioning:
+ base: image0
+ label: gpt
+ partitions:
+ - name: ESP
+ type: 'EF00'
+ size: 64MiB
+ mkfs:
+ type: vfat
+ mount:
+ mount_point: /boot/efi
+ fstab:
+ options: "defaults"
+ fsck-passno: 1
+ - name: root
+ type: '8300'
+ size: 50GiB
+ mkfs:
+ type: ext4
+ mount:
+ mount_point: /
+ fstab:
+ options: "defaults"
+ fsck-passno: 1
+ "
+
+ export DIB_YUM_REPO_CONF+="/etc/yum.repos.d/delorean-deps-rocky.repo /etc/yum.repos.d/delorean-rocky.repo /etc/yum.repos.d
+ /epel.repo "
+ openstack --debug overcloud image build --config-file undercloud_full.yaml --output-directory ./
+
+
+The overcloud is built in a similar way.
+
+.. code-block:: python
+
+ export DIB_YUM_REPO_CONF+="/etc/yum.repos.d/delorean-deps-rocky.repo /etc/yum.repos.d/delorean-rocky.repo /etc/yum.repos.d
+ /epel.repo "
+ openstack --debug overcloud image build --config-file overcloud_full_rootfs.yaml --output-directory ./
+
+
+
+Apex container deployment
+-------------------------
+Similarly the containers provided by OOO are for x86 only. Containers for apex on aarch64 for the Rocky release can
+be found in armbandapex_.
+
+.. _armbandapex: https://registry.hub.docker.com/v2/repositories/armbandapex/
+
+A user who wishes to rebuild the containers can easily do so by sing Kolla. An example kolla.conf and the command to build the containers is given bellow.
+
+
+.. code-block:: python
+
+ [DEFAULT]
+
+ base=centos
+ type=binary
+ namespace="private docker.io repository"
+ tag=current-tripleo-rdo
+ rpm_setup_config=ceph.repo,epel.repo,delorean-deps.repo,delorean.repo
+ push=True
+
+
+
+.. code-block:: python
+
+ openstack overcloud container image build --config-file /usr/share/tripleo-common/container-images/overcloud_containers.yaml
+ --kolla-config-file /etc/kolla/kolla-build.conf
+
+
diff --git a/docs/contributor/upstream-overcloud-container-design.rst b/docs/contributor/upstream-overcloud-container-design.rst
new file mode 100644
index 0000000..4b368c2
--- /dev/null
+++ b/docs/contributor/upstream-overcloud-container-design.rst
@@ -0,0 +1,126 @@
+=======================================
+Overcloud Container Design/Architecture
+=======================================
+
+This document describes the changes done to implement container deployments in
+Apex.
+
+ * OOO container architecture
+ * Upstream vs Downstream deployment
+ * Apex container deployment overview
+
+OOO container architecture
+--------------------------
+
+Typically in OOO each OpenStack service is represented by a TripleO Heat
+Template stored under the puppet/services directory in the THT code base. For
+containers, there are new templates created in the docker/services directory
+which include templates for most of the previously defined puppet services.
+These docker templates in almost all cases inherit their puppet template
+counterpart and then build off of that to provide OOO docker specific
+configuration.
+
+The containers configuration in OOO is still done via puppet, and config files
+are then copied into a host directory to be later mounted in the service
+container during deployment. The docker template contains docker specific
+settings to the service, including what files to mount into the container,
+along with which puppet resources to execute, etc. Note, the puppet code is
+still stored locally on the host, while the service python code is stored in
+the container image.
+
+RDO has its own registry which stores the Docker images per service to use in
+deployments. The container image is usually just a CentOS 7 container with the
+relevant service RPM installed.
+
+In addition, Ceph no longer uses puppet to deploy. puppet-ceph was previously
+used to configure Ceph on the overcloud, but has been replaced with
+Ceph-Ansible. During container deployment, the undercloud calls a mistral
+workflow to initiate a Ceph-Ansible playbook that will download the Ceph Daemon
+container image to the overcloud and configure it.
+
+Upstream vs. Downstream deployment
+----------------------------------
+
+In Apex we typically build artifacts and then deploy from them. This works in
+the past as we usually modify disk images (qcow2s) with files or patches and
+distribute them as RPMs. However, with containers space becomes an issue. The
+size of each container image ranges from 800 MB to over 2GB. This makes it
+unfeasible to download all of the possible images and store them into a disk
+image for distribution.
+
+Therefore for container deployments the only option is to deploy using
+upstream. This means that only upstream undercloud/overcloud images are pulled
+at deploy time, and the required containers are docker pulled during deployment
+into the undercloud. For upstream deployments the modified time of the
+RDO images are checked and cached locally, to refrain from unnecessary
+downloading of artifacts. Also, the optional '--no-fetch' argument may be
+provided at deploy time, to ignore pulling any new images, as long as previous
+artifacts are cached locally.
+
+Apex container deployment
+-------------------------
+
+For deploying containers with Apex, a new deploy setting is available,
+'containers'. When this flag is used, along with '--upstream' the following
+workflow occurs:
+
+ 1. The upstream RDO images for undercloud/overcloud are checked and
+ downloaded if necessary.
+ 2. The undercloud VM is installed and configured as a normal deployment.
+ 3. The overcloud prep image method is called which is modified now for
+ patches and containers. The method will now return a set of container
+ images which are going to be patched. These can be either due to a change
+ in OpenDaylight version for example, or patches included in the deploy
+ settings for the overcloud that include a python path.
+ 4. During the overcloud image prep, a new directory in the Apex tmp dir is
+ created called 'containers' which then includes sub-directories for each
+ docker image which is being patched (for example, 'containers/nova-api').
+ 5. A Dockerfile is created inside of the directory created in step 4, which
+ holds Dockerfile operations to rebuild the container with patches or any
+ required changes. Several container images could be used for different
+ services inside of an OS project. For example, there are different images
+ for each nova service (nova-api, nova-conductor, nova-compute). Therefore
+ a lookup is done to figure out all of the container images that a
+ hypothetically provided nova patch would apply to. Then a directory and
+ Dockerfile is created for each image. All of this is tar'ed and
+ compressed into an archive which will be copied to the undercloud.
+ 6. Next, the deployment is checked to see if a Ceph devices was provided in
+ Apex settings. If it is not, then a persistent loop device is created
+ in the overcloud image to serve as storage backend for Ceph OSDs. Apex
+ previously used a directory '/srv/data' to serve as the backend to the
+ OSDs, but that is no longer supported with Ceph-Ansible.
+ 7. The deployment command is then created, as usual, but with minor changes
+ to add docker.yaml and docker-ha.yaml files which are required to deploy
+ containers with OOO.
+ 8. Next a new playbook is executed, 'prepare_overcloud_containers.yaml',
+ which includes several steps:
+
+ a. The previously archived docker image patches are copied and unpacked
+ into /home/stack.
+ b. 'overcloud_containers' and 'sdn_containers' image files are then
+ prepared which are basically just yaml files which indicate which
+ docker images to pull and where to store them. Which in our case is a
+ local docker registry.
+ c. The docker images are then pulled and stored into the local registry.
+ The reason for using a local registry is to then have a static source
+ of images that do not change every time a user deploys. This allows
+ for more control and predictability in deployments.
+ d. Next, the images in the local registry are cross-checked against
+ the images that were previously collected as requiring patches. Any
+ image which then exists in the local registry and also requires changes
+ is then rebuilt by the docker build command, tagged with 'apex' and
+ then pushed into the local registry. This helps the user distinguish
+ which containers have been modified by Apex, in case any debugging is
+ needed in comparing upstream docker images with Apex modifications.
+ e. Then new OOO image files are created, to indicate to OOO that the
+ docker images to use for deployment are the ones in the local registry.
+ Also, the ones modified by Apex are modified with the 'apex' tag.
+ f. The relevant Ceph Daemon Docker image is pulled and pushed into the
+ local registry for deployment.
+ 9. At this point the OOO deployment command is initiated as in regular
+ Apex deployments. Each container will be started on the overcloud and
+ puppet executed in it to gather the configuration files in Step 1. This
+ leads to Step 1 taking longer than it used to in non-containerized
+ deployments. Following this step, the containers are then brought up in
+ their regular step order, while mounting the previously generated
+ configuration files.
diff --git a/docs/index.rst b/docs/index.rst
new file mode 100644
index 0000000..2fd1b4a
--- /dev/null
+++ b/docs/index.rst
@@ -0,0 +1,23 @@
+.. _apex:
+
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. SPDX-License-Identifier CC-BY-4.0
+.. (c) Open Platform for NFV Project, Inc. and its contributors
+
+*********************************
+OPNFV Apex
+*********************************
+
+.. toctree::
+ :numbered:
+ :maxdepth: 3
+
+ release/scenarios/os-nosdn-nofeature-noha/index
+ release/scenarios/os-ovn-nofeature-ha/index
+ release/scenarios/os-nosdn-nofeature-ha/index
+ release/scenarios/os-odl-nofeature-noha/index
+ release/scenarios/os-odl-nofeature-ha/index
+ release/scenarios/k8s-nosdn-nofeature-noha/index
+ release/installation/index
+ release/release-notes/index
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
diff --git a/docs/release/release-notes/release-notes.rst b/docs/release/release-notes/release-notes.rst
index 4be2e65..159165d 100644
--- a/docs/release/release-notes/release-notes.rst
+++ b/docs/release/release-notes/release-notes.rst
@@ -1,11 +1,11 @@
-===========================================================================
-OPNFV Release Notes for the Euphrates release of OPNFV Apex deployment tool
-===========================================================================
+========================================================================
+OPNFV Release Notes for the Gambia release of OPNFV Apex deployment tool
+========================================================================
Abstract
========
-This document provides the release notes for Euphrates release with the Apex
+This document provides the release notes for Gambia release with the Apex
deployment toolchain.
License
@@ -17,7 +17,7 @@ All Apex and "common" entities are protected by the Apache 2.0 License
Important Notes
===============
-This is the OPNFV Euphrates release that implements the deploy stage of the
+This is the OPNFV Gambia release that implements the deploy stage of the
OPNFV CI pipeline via Apex.
Apex is based on RDO's Triple-O installation tool chain.
@@ -29,14 +29,14 @@ deploy OPNFV using Apex installer.
Summary
=======
-Euphrates release with the Apex deployment toolchain will establish an OPNFV
+Gambia release with the Apex deployment toolchain will establish an OPNFV
target system on a Pharos compliant lab infrastructure. The current definition
-of an OPNFV target system is OpenStack Newton combined with an SDN
+of an OPNFV target system is OpenStack Pike combined with an SDN
controller, such as OpenDaylight. The system is deployed with OpenStack High
Availability (HA) for most OpenStack services. SDN controllers are deployed
on every controller unless deploying with one the HA FD.IO scenarios. Ceph
storage is used as Cinder backend, and is the only supported storage for
-Euphrates. Ceph is setup as 3 OSDs and 3 Monitors, one OSD+Mon per Controller
+Gambia. 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
@@ -46,7 +46,7 @@ simulate the a bare metal deployment.
- Documentation is built by Jenkins
- .iso image is built by Jenkins
- .rpm packages are built by Jenkins
-- Jenkins deploys a Euphrates release with the Apex deployment toolchain
+- Jenkins deploys a Gambia release with the Apex deployment toolchain
bare metal, which includes 3 control+network nodes, and 2 compute nodes.
Release Data
@@ -56,16 +56,16 @@ Release Data
| **Project** | apex |
| | |
+--------------------------------------+--------------------------------------+
-| **Repo/tag** | apex/euphrates.1.0 |
+| **Repo/tag** | opnfv-7.1.0 |
| | |
+--------------------------------------+--------------------------------------+
-| **Release designation** | 5.0.0 |
+| **Release designation** | 7.1.0 |
| | |
+--------------------------------------+--------------------------------------+
-| **Release date** | 2017-10-20 |
+| **Release date** | 2018-12-14 |
| | |
+--------------------------------------+--------------------------------------+
-| **Purpose of the delivery** | OPNFV Euphrates release |
+| **Purpose of the delivery** | OPNFV Gambia release |
| | |
+--------------------------------------+--------------------------------------+
@@ -74,159 +74,44 @@ Version change
Module version changes
~~~~~~~~~~~~~~~~~~~~~~
-This is the first tracked version of the Euphrates release with the Apex
-deployment toolchain. It is based on following upstream versions:
+This is the first tracked version of the Gambia release with the Apex
+deployment toolchain. It is based on following upstream versions:
-- OpenStack (Newton release)
+- OpenStack (Queens release)
-- OpenDaylight (Carbon/Nitrogen(master) releases)
+- OpenDaylight (Oxygen releases)
- CentOS 7
Document Version Changes
~~~~~~~~~~~~~~~~~~~~~~~~
-This is the first tracked version of Euphrates release with the Apex
+This is the first tracked version of Gambia release with the Apex
deployment toolchain.
The following documentation is provided with this release:
-- OPNFV Installation instructions for the Euphrates release with the Apex
+- OPNFV Installation instructions for the Gambia release with the Apex
deployment toolchain - ver. 1.0.0
-- OPNFV Release Notes for the Euphrates release with the Apex deployment
+- OPNFV Release Notes for the Gambia release with the Apex deployment
toolchain - ver. 1.0.0 (this document)
-Feature Additions
-~~~~~~~~~~~~~~~~~
-
-+--------------------------------------+--------------------------------------+
-| **JIRA REFERENCE** | **SLOGAN** |
-| | |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-129 | Adds OVN SDN Controller support |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-299 | Migrate to OpenStack Newton |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-150 | Allow for multiple external networks |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-301 | Support Networking ODL v2 Driver |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-300 | Support OpenDaylight new netvirt |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-302 | Upstream Tacker and Congress |
-| | support |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-106 | Enable CPU pinning for Overcloud |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-390 | OpenDaylight HA as default for HA |
-| | scenarios |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-357 | Include Quagga in SDNVPN scenario |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-262 | Migrate to new network settings |
-| | format |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-128 | Adds Real Time KVM support |
-+--------------------------------------+--------------------------------------+
-
-Bug Corrections
-~~~~~~~~~~~~~~~
-
-**JIRA TICKETS:**
-
-+--------------------------------------+--------------------------------------+
-| **JIRA REFERENCE** | **SLOGAN** |
-| | |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-208 | Need ability to specify which nic |
-| | to place vlan on |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-215 | Keystone services not configured and |
-| | error is silently ignored on VLAN |
-| | Deployments |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-221 | NoHA virtual deployments should use 1|
-| | compute |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-276 | ODL HA is unstable and crashes |
-| | frequently |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-287 | Name mismatch for package openstack- |
-| | congress during overcloud build |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-339 | Enable pinning for OVS DPDK |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-345 | Horizon and cloud failures due to |
-| | running out of file descriptors for |
-| | MariaDB in noha deployments |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-370 | ISO builds fail in Danube |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-372 | Specifying same NIC for storage and |
-| | private network but different VLANs |
-| | results in duplicate NIC error |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-373 | Running smoke tests should install |
-| | Ansible onto jump host |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-374 | Ceph accidentally disabled by default|
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-378 | OVS 2.5.90 NSH build fails |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-382 | yum update on undercloud breaks |
-| | deployments |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-386 | Fix os-net-config to match upstream |
-| | stable/newton |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-398 | Tacker uses "RegionOne" instead of |
-| | "regionOne" |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-399 | hugepages are not enabled when |
-| | configured in deploy settings |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-403 | Remove Quagga from build process and |
-| | cache to artifacts |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-406 | ODL FDIO neutron patches to all |
-| | scenarios |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-407 | VPP service does not start upon |
-| | reboot |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-408 | Quagga's bgpd cannot start due to |
-| | permissions |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-421 | Update odl/hc/vpp versions for odl_l3|
-| | noha |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-426 | Missing virtual-computes arg in help |
-| | output for deploy |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-427 | Neutron openvswitch agent starts when|
-| | openvswitch is restarted |
-+--------------------------------------+--------------------------------------+
-
Deliverables
------------
Software Deliverables
~~~~~~~~~~~~~~~~~~~~~
-- Apex .iso file
-- Apex release .rpm (opnfv-apex-release)
-- Apex overcloud .rpm (opnfv-apex) - For nosdn and OpenDaylight Scenarios
-- Apex undercloud .rpm (opnfv-apex-undercloud)
-- Apex common .rpm (opnfv-apex-common)
-- build.py - Builds the above artifacts
+- Apex .rpm (python34-opnfv-apex)
+- build.py - Builds the above artifact
- opnfv-deploy - Automatically deploys Target OPNFV System
- opnfv-clean - Automatically resets a Target OPNFV Deployment
- opnfv-util - Utility to connect to or debug Overcloud nodes + OpenDaylight
Documentation Deliverables
~~~~~~~~~~~~~~~~~~~~~~~~~~
-- OPNFV Installation instructions for the Euphrates release with the Apex
- deployment toolchain - ver. 5.0
-- OPNFV Release Notes for the Euphrates release with the Apex deployment
- toolchain - ver. 5.0 (this document)
+- OPNFV Installation instructions for the Gambia release with the Apex
+ deployment toolchain - ver. 7.1
+- OPNFV Release Notes for the Gambia release with the Apex deployment
+ toolchain - ver. 7.1 (this document)
Known Limitations, Issues and Workarounds
=========================================
@@ -253,18 +138,12 @@ Known Issues
| **JIRA REFERENCE** | **SLOGAN** |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: APEX-138 | Unclear error message when interface |
-| | set to dhcp |
-+--------------------------------------+--------------------------------------+
| JIRA: APEX-280 | Deleted network not cleaned up |
| | on controller |
+--------------------------------------+--------------------------------------+
| JIRA: APEX-295 | Missing support for VLAN tenant |
| | networks |
+--------------------------------------+--------------------------------------+
-| JIRA: APEX-352 | Package "openstack-utils" is |
-| | missing from overcloud |
-+--------------------------------------+--------------------------------------+
| JIRA: APEX-368 | Ceilometer stores samples and events |
| | forever |
+--------------------------------------+--------------------------------------+
@@ -277,20 +156,8 @@ Known Issues
| JIRA: APEX-389 | Compute kernel parameters are used |
| | for all nodes |
+--------------------------------------+--------------------------------------+
-| JIRA: APEX-410 | Need to limit number of workers per |
-| | OpenStack service for baremetal |
-| | deployments |
-+--------------------------------------+--------------------------------------+
| JIRA: APEX-412 | Install failures with UEFI |
+--------------------------------------+--------------------------------------+
-| JIRA: APEX-417 | Missing OVS 2.6 + NSH support |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-419 | opnfv-clean sometimes leaves admin |
-| | and public network down |
-+--------------------------------------+--------------------------------------+
-| JIRA: APEX-425 | Need to tweak performance settings |
-| | virtual DPDK scenarios |
-+--------------------------------------+--------------------------------------+
Workarounds
@@ -308,10 +175,10 @@ Apex installer.
References
==========
-For more information on the OPNFV Euphrates release, please see:
+For more information on the OPNFV Gambia release, please see:
-http://wiki.opnfv.org/releases/Euphrates
+http://wiki.opnfv.org/releases/Gambia
:Authors: Tim Rozet (trozet@redhat.com)
:Authors: Dan Radez (dradez@redhat.com)
-:Version: 5.0
+:Version: 7.1
diff --git a/docs/release/scenarios/os-nosdn-performance-ha/index.rst b/docs/release/scenarios/k8s-nosdn-nofeature-noha/index.rst
index e0dbca7..6efd74c 100644
--- a/docs/release/scenarios/os-nosdn-performance-ha/index.rst
+++ b/docs/release/scenarios/k8s-nosdn-nofeature-noha/index.rst
@@ -1,15 +1,15 @@
-.. _os-nosdn-performance-ha:
+.. _k8s-nosdn-nofeature-noha:
.. This work is licensed under a Creative Commons Attribution 4.0 International Licence.
.. http://creativecommons.org/licenses/by/4.0
.. (c) <optionally add copywriters name>
-================================================
-os-nosdn-performance-ha overview and description
-================================================
+=================================================
+k8s-nosdn-nofeature-noha overview and description
+=================================================
.. toctree::
:numbered:
:maxdepth: 4
- os-nosdn-performance-ha.rst
+ k8s-nosdn-nofeature-noha.rst
diff --git a/docs/release/scenarios/k8s-nosdn-nofeature-noha/k8s-nosdn-nofeature-noha.rst b/docs/release/scenarios/k8s-nosdn-nofeature-noha/k8s-nosdn-nofeature-noha.rst
new file mode 100644
index 0000000..7ff21b7
--- /dev/null
+++ b/docs/release/scenarios/k8s-nosdn-nofeature-noha/k8s-nosdn-nofeature-noha.rst
@@ -0,0 +1,46 @@
+.. 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 Gambia 1.1 of
+Kubernetes deployment with no SDN controller, no extra features
+and no High Availability enabled. Note this scenario is *not* supported
+for Gambia initial release and will be supported in a later service release
+of Gambia.
+
+============
+Introduction
+============
+
+This scenario is used primarily to validate and deploy a Kubernetes
+deployment without any NFV features or SDN controller enabled.
+
+Scenario components and composition
+===================================
+
+This scenario deploys a Kubernetes cluster on bare metal or virtual
+environment with a single master node. TripleO is used to bootstrap
+all the nodes and set up basic services like SSH. An undercloud VM
+used similarly to Openstack deployments, however no Openstack services
+(Nova, Neutron, Keystone, etc) will be deployed to the nodes. After
+TripleO successfully executes all the bootstrapping tasks, Kubespray
+is run (using ansible) to deploy Kubernetes cluster on the nodes.
+
+
+Scenario usage overview
+=======================
+
+Simply deploy this scenario by using the k8s-nosdn-nofeature-noha.yaml deploy
+settings file.
+
+Limitations, Issues and Workarounds
+===================================
+
+None
+
+References
+==========
+
+For more information on the OPNFV Gambia release, please visit
+http://www.opnfv.org/gambia
+
diff --git a/docs/release/scenarios/os-nosdn-nofeature-ha/os-nosdn-nofeature-ha.rst b/docs/release/scenarios/os-nosdn-nofeature-ha/os-nosdn-nofeature-ha.rst
index 0aa72ba..5f2839c 100644
--- a/docs/release/scenarios/os-nosdn-nofeature-ha/os-nosdn-nofeature-ha.rst
+++ b/docs/release/scenarios/os-nosdn-nofeature-ha/os-nosdn-nofeature-ha.rst
@@ -2,14 +2,14 @@
.. http://creativecommons.org/licenses/by/4.0
.. (c) <optionally add copywriters name>
-This document provides scenario level details for Euphrates 1.0 of
+This document provides scenario level details for Gambia 1.1 of
deployment with no SDN controller and no extra features enabled.
============
Introduction
============
-This scenario is used primarily to validate and deploy a Newton OpenStack
+This scenario is used primarily to validate and deploy a Queens OpenStack
deployment without any NFV features or SDN controller enabled.
Scenario components and composition
@@ -38,6 +38,6 @@ None
References
==========
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
+For more information on the OPNFV Gambia release, please visit
+http://www.opnfv.org/gambia
diff --git a/docs/release/scenarios/os-nosdn-nofeature-noha/os-nosdn-nofeature-noha.rst b/docs/release/scenarios/os-nosdn-nofeature-noha/os-nosdn-nofeature-noha.rst
index 6889f7d..e5d4c98 100644
--- a/docs/release/scenarios/os-nosdn-nofeature-noha/os-nosdn-nofeature-noha.rst
+++ b/docs/release/scenarios/os-nosdn-nofeature-noha/os-nosdn-nofeature-noha.rst
@@ -2,14 +2,14 @@
.. http://creativecommons.org/licenses/by/4.0
.. (c) <optionally add copywriters name>
-This document provides scenario level details for Euphrates 1.0 of
+This document provides scenario level details for Gambia 1.1 of
deployment with no SDN controller and no extra features enabled.
============
Introduction
============
-This scenario is used primarily to validate and deploy a Newton OpenStack
+This scenario is used primarily to validate and deploy a Queens OpenStack
deployment without any NFV features or SDN controller enabled.
Scenario components and composition
@@ -35,6 +35,6 @@ None
References
==========
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
+For more information on the OPNFV Gambia release, please visit
+http://www.opnfv.org/gambia
diff --git a/docs/release/scenarios/os-nosdn-ovs_dpdk-ha/index.rst b/docs/release/scenarios/os-nosdn-ovs_dpdk-ha/index.rst
deleted file mode 100644
index febf16c..0000000
--- a/docs/release/scenarios/os-nosdn-ovs_dpdk-ha/index.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. _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
deleted file mode 100644
index 3908385..0000000
--- a/docs/release/scenarios/os-nosdn-ovs_dpdk-ha/os-nosdn-ovs_dpdk-ha.rst
+++ /dev/null
@@ -1,87 +0,0 @@
-.. 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.
-
-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
deleted file mode 100644
index 699f391..0000000
--- a/docs/release/scenarios/os-nosdn-ovs_dpdk-noha/index.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. _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
deleted file mode 100644
index be0f37d..0000000
--- a/docs/release/scenarios/os-nosdn-ovs_dpdk-noha/os-nosdn-ovs_dpdk-noha.rst
+++ /dev/null
@@ -1,87 +0,0 @@
-.. 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.
-
-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
diff --git a/docs/release/scenarios/os-nosdn-performance-ha/os-nosdn-performance-ha.rst b/docs/release/scenarios/os-nosdn-performance-ha/os-nosdn-performance-ha.rst
deleted file mode 100644
index 6437ce1..0000000
--- a/docs/release/scenarios/os-nosdn-performance-ha/os-nosdn-performance-ha.rst
+++ /dev/null
@@ -1,54 +0,0 @@
-.. 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 performance options enabled.
-
-============
-Introduction
-============
-
-This scenario is used primarily to demonstrate the performance settings and
-capabilities in Apex. This scenario will deploy a Newton OpenStack
-deployment without any NFV features or SDN controller enabled.
-
-Scenario components and composition
-===================================
-
-This scenario is composed of common OpenStack services enabled by default,
-including Nova, Neutron, Glance, Cinder, Keystone, Horizon. Optionally and
-by default, Tacker and Congress services are also enabled. Ceph is used as
-the backend storage to Cinder on all deployed nodes.
-
-All services are in HA, meaning that there are multiple cloned instances of
-each service, and they are balanced by HA Proxy using a Virtual IP Address
-per service.
-
-The main purpose of this scenario is to serve as an example to show how to
-set optional performance settings in an Apex deploy settings file.
-
-Scenario usage overview
-=======================
-
-The performance options listed in os-nosdn-performance-ha.yaml give an example
-of the different options a user can set in any deploy settings file. Some
-of these performance options are actually required for other scenarios which
-rely on DPDK. Options under the nova section like 'libvirtpin' allow a
-user to choose which core to pin nova instances to on the overcloud compute
-node. Options under 'kernel' allow a user to set kernel specific arguments
-at boot, which include options like hugepages, isolcpus, enabling iommu, etc.
-
-
-Limitations, Issues and Workarounds
-===================================
-
-* `APEX-389 <https://jira.opnfv.org/browse/APEX-389>`_:
- Compute kernel parameters are applied to all nodes
-
-References
-==========
-
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
-
diff --git a/docs/release/scenarios/os-odl-csit-noha/index.rst b/docs/release/scenarios/os-odl-csit-noha/index.rst
deleted file mode 100644
index 51cf903..0000000
--- a/docs/release/scenarios/os-odl-csit-noha/index.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-.. _os-odl-csit-noha:
-
-.. This work is licensed under a Creative Commons Attribution 4.0 International Licence.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) <optionally add copywriters name>
-
-=========================================
-os-odl-csit-noha overview and description
-=========================================
-
-.. toctree::
- :numbered:
- :maxdepth: 4
-
- os-odl-csit-noha.rst
diff --git a/docs/release/scenarios/os-odl-csit-noha/os-odl-csit-noha.rst b/docs/release/scenarios/os-odl-csit-noha/os-odl-csit-noha.rst
deleted file mode 100644
index b75c435..0000000
--- a/docs/release/scenarios/os-odl-csit-noha/os-odl-csit-noha.rst
+++ /dev/null
@@ -1,54 +0,0 @@
-.. 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 the OpenDaylight SDN controller and only CSIT relevant
-features enabled.
-
-============
-Introduction
-============
-
-This scenario is used primarily to validate and deploy a minimum Newton
-OpenStack + OpenDaylight deployment with only required OpenStack services.
-
-Scenario components and composition
-===================================
-
-This scenario is composed of only required OpenStack services enabled by
-default, including Nova, Neutron, Glance, and Keystone. OpenDaylight is also
-enabled. File storage is used as the backend to Glance.
-
-The purpose of this file is to deploy a minimum OpenStack setup that will
-still be able to exercise OpenDaylight. The use case for this scenario is
-to be able to test OpenDaylight quickly in an environment with low
-CPU/Memory requirements.
-
-
-Scenario usage overview
-=======================
-
-Simply deploy this scenario by using the os-odl-csit-noha.yaml deploy
-settings file.
-
-Limitations, Issues and Workarounds
-===================================
-
-* `APEX-112 <https://jira.opnfv.org/browse/APEX-112>`_:
- ODL routes local subnet traffic to GW
-* `APEX-149 <https://jira.opnfv.org/browse/APEX-149>`_:
- OpenFlow rules are populated very slowly
-* `APEX-268 <https://jira.opnfv.org/browse/APEX-268>`_:
- VMs with multiple floating IPs can only access via first NIC
-* `APEX-384 <https://jira.opnfv.org/browse/APEX-384>`_:
- Not including odl_version in deploy settings causes error
-* `APEX-422 <https://jira.opnfv.org/browse/APEX-422>`_:
- First nova instance DHCP request fails
-
-References
-==========
-
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
-
diff --git a/docs/release/scenarios/os-odl-nofeature-ha/os-odl-nofeature-ha.rst b/docs/release/scenarios/os-odl-nofeature-ha/os-odl-nofeature-ha.rst
index e5561a7..111ba6f 100644
--- a/docs/release/scenarios/os-odl-nofeature-ha/os-odl-nofeature-ha.rst
+++ b/docs/release/scenarios/os-odl-nofeature-ha/os-odl-nofeature-ha.rst
@@ -2,14 +2,14 @@
.. http://creativecommons.org/licenses/by/4.0
.. (c) <optionally add copywriters name>
-This document provides scenario level details for Euphrates 1.0 of
+This document provides scenario level details for Gambia 1.1 of
deployment with the OpenDaylight SDN controller and no extra features enabled.
============
Introduction
============
-This scenario is used primarily to validate and deploy a Newton OpenStack
+This scenario is used primarily to validate and deploy a Queens OpenStack
deployment with OpenDaylight, and without any NFV features enabled.
Scenario components and composition
@@ -38,20 +38,12 @@ settings file.
Limitations, Issues and Workarounds
===================================
-* `APEX-112 <https://jira.opnfv.org/browse/APEX-112>`_:
- ODL routes local subnet traffic to GW
-* `APEX-149 <https://jira.opnfv.org/browse/APEX-149>`_:
- OpenFlow rules are populated very slowly
* `APEX-268 <https://jira.opnfv.org/browse/APEX-268>`_:
VMs with multiple floating IPs can only access via first NIC
-* `APEX-384 <https://jira.opnfv.org/browse/APEX-384>`_:
- Not including odl_version in deploy settings causes error
-* `APEX-422 <https://jira.opnfv.org/browse/APEX-422>`_:
- First nova instance DHCP request fails
References
==========
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
+For more information on the OPNFV Gambia release, please visit
+http://www.opnfv.org/gambia
diff --git a/docs/release/scenarios/os-odl-nofeature-noha/os-odl-nofeature-noha.rst b/docs/release/scenarios/os-odl-nofeature-noha/os-odl-nofeature-noha.rst
index f04e7c0..3e26d67 100644
--- a/docs/release/scenarios/os-odl-nofeature-noha/os-odl-nofeature-noha.rst
+++ b/docs/release/scenarios/os-odl-nofeature-noha/os-odl-nofeature-noha.rst
@@ -2,14 +2,14 @@
.. http://creativecommons.org/licenses/by/4.0
.. (c) <optionally add copywriters name>
-This document provides scenario level details for Euphrates 1.0 of
+This document provides scenario level details for Gambia 1.1 of
deployment with the OpenDaylight SDN controller and no extra features enabled.
============
Introduction
============
-This scenario is used primarily to validate and deploy a Newton OpenStack
+This scenario is used primarily to validate and deploy a Queens OpenStack
deployment with OpenDaylight, and without any NFV features enabled.
Scenario components and composition
@@ -32,20 +32,12 @@ settings file.
Limitations, Issues and Workarounds
===================================
-* `APEX-112 <https://jira.opnfv.org/browse/APEX-112>`_:
- ODL routes local subnet traffic to GW
-* `APEX-149 <https://jira.opnfv.org/browse/APEX-149>`_:
- OpenFlow rules are populated very slowly
* `APEX-268 <https://jira.opnfv.org/browse/APEX-268>`_:
VMs with multiple floating IPs can only access via first NIC
-* `APEX-384 <https://jira.opnfv.org/browse/APEX-384>`_:
- Not including odl_version in deploy settings causes error
-* `APEX-422 <https://jira.opnfv.org/browse/APEX-422>`_:
- First nova instance DHCP request fails
References
==========
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
+For more information on the OPNFV Gambia release, please visit
+http://www.opnfv.org/gambia
diff --git a/docs/release/scenarios/os-ovn-nofeature-noha/index.rst b/docs/release/scenarios/os-ovn-nofeature-ha/index.rst
index 7454504..b7e62e6 100644
--- a/docs/release/scenarios/os-ovn-nofeature-noha/index.rst
+++ b/docs/release/scenarios/os-ovn-nofeature-ha/index.rst
@@ -1,4 +1,4 @@
-.. _os-ovn-nofeature-noha:
+.. _os-ovn-nofeature-ha:
.. This work is licensed under a Creative Commons Attribution 4.0 International Licence.
.. http://creativecommons.org/licenses/by/4.0
@@ -12,4 +12,4 @@ os-ovn-nofeature-noha overview and description
:numbered:
:maxdepth: 4
- os-ovn-nofeature-noha.rst
+ os-ovn-nofeature-ha.rst
diff --git a/docs/release/scenarios/os-ovn-nofeature-noha/os-ovn-nofeature-noha.rst b/docs/release/scenarios/os-ovn-nofeature-ha/os-ovn-nofeature-ha.rst
index a838e4b..165b5f7 100644
--- a/docs/release/scenarios/os-ovn-nofeature-noha/os-ovn-nofeature-noha.rst
+++ b/docs/release/scenarios/os-ovn-nofeature-ha/os-ovn-nofeature-ha.rst
@@ -2,14 +2,14 @@
.. http://creativecommons.org/licenses/by/4.0
.. (c) <optionally add copywriters name>
-This document provides scenario level details for Euphrates 1.0 of
+This document provides scenario level details for Gambia 1.1 of
deployment with the OVN SDN controller and no extra features enabled.
============
Introduction
============
-This scenario is used primarily to validate and deploy a Newton OpenStack
+This scenario is used primarily to validate and deploy a Pike OpenStack
deployment with the OVN SDN controller, and without any NFV features enabled.
Scenario components and composition
@@ -23,18 +23,17 @@ the backend storage to Cinder on all deployed nodes.
Scenario usage overview
=======================
-Simply deploy this scenario by using the os-ovn-nofeature-noha.yaml deploy
+Simply deploy this scenario by using the os-ovn-nofeature-ha.yaml deploy
settings file.
Limitations, Issues and Workarounds
===================================
-* `APEX-430 <https://jira.opnfv.org/browse/APEX-430>`_:
- OVN HA functionality is not available.
+None
References
==========
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
+For more information on the OPNFV Gambia release, please visit
+http://www.opnfv.org/gambia
diff --git a/docs/requirements.txt b/docs/requirements.txt
new file mode 100644
index 0000000..9fde2df
--- /dev/null
+++ b/docs/requirements.txt
@@ -0,0 +1,2 @@
+lfdocs-conf
+sphinx_opnfv_theme