Abstract
========
-This document describes how to install the Euphrates release of OPNFV when
+This document describes how to install the Fraser 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)
+Fraser 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
+Fraser 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/>.
+-------------------------+-------------+---------------+
| os-nosdn-bar-noha | Barometer | Yes |
+-------------------------+-------------+---------------+
-| os-nosdn-calipso-noha | Calipso | Yes |
+| os-nosdn-calipso-noha | Calipso | No |
+-------------------------+-------------+---------------+
-| 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 |
+-------------------------+-------------+---------------+
+-------------------------+-------------+---------------+
| os-odl-sfc-ha | SFC | No |
+-------------------------+-------------+---------------+
-| os-odl-sfc-noha | SFC | Yes |
+| os-odl-sfc-noha | SFC | No |
+-------------------------+-------------+---------------+
| os-odl-gluon-noha | Gluon | No |
+-------------------------+-------------+---------------+
| 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 |
+-------------------------+-------------+---------------+
``sudo yum install https://repos.fedorapeople.org/repos/openstack/openstack-pike/rdo-release-pike-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/fraser/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
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: 6.0
Indices and tables
==================
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 Fraser reference
+platform using the Apex installer.
The audience is assumed to have a good background in networking
and Linux administration.
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
+(``opnfv-apex-fraser.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
OpenStack
---------
-`OpenStack Newton Release artifacts <http://www.openstack.org/software/newton>`_
+`OpenStack Pike Release artifacts <http://www.openstack.org/software/pike>`_
`OpenStack documentation <http://docs.openstack.org>`_
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
-----------
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 Fraser Apex RPMs and their dependencies.
6. 16 GB of RAM for a bare metal deployment, 64 GB of RAM for a Virtual
Deployment.
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.
--- /dev/null
+Deploying Directly from Upstream - (Beta)
+=========================================
+
+In addition to deploying with OPNFV tested artifacts included in the
+opnfv-apex-undercloud and opnfv-apex RPMs, it is now possible to deploy
+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 deploy newer versions of OpenStack that are not included
+with this release, and offers some significant advantages for some users.
+Please note this feature is currently in beta for the Fraser release and will
+be fully supported in the next OPNFV release.
+
+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
+------------------------------------------------------
+
+Some deploy settings files are already provided which have been tested by the
+Apex team. These include (under /etc/opnfv-apex/):
+
+ - os-nosdn-queens_upstream-noha.yaml
+ - os-nosdn-master_upstream-noha.yaml
+ - os-odl-queens_upstream-noha.yaml
+ - os-odl-master_upstream-noha.yaml
+
+Each of these scenarios has been tested by Apex over the Fraser release, but
+none are guaranteed to work as upstream is a moving target and this feature is
+relatively new. Still it is the goal of the Apex team to provide support
+and move to an upstream based deployments in the future, so please file a bug
+when encountering any issues.
+
+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. In order to use an upstream deployment, please use the ``--upstream``
+argument. Also, 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 Release Notes for the Euphrates release of OPNFV Apex deployment tool
-===========================================================================
+========================================================================
+OPNFV Release Notes for the Fraser 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 Fraser release with the Apex
deployment toolchain.
License
Important Notes
===============
-This is the OPNFV Euphrates release that implements the deploy stage of the
+This is the OPNFV Fraser release that implements the deploy stage of the
OPNFV CI pipeline via Apex.
Apex is based on RDO's Triple-O installation tool chain.
Summary
=======
-Euphrates release with the Apex deployment toolchain will establish an OPNFV
+Fraser 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
+Fraser. 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
- 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 Fraser release with the Apex deployment toolchain
bare metal, which includes 3 control+network nodes, and 2 compute nodes.
Release Data
| **Project** | apex |
| | |
+--------------------------------------+--------------------------------------+
-| **Repo/tag** | apex/euphrates.1.0 |
+| **Repo/tag** | opnfv-6.0.0 |
| | |
+--------------------------------------+--------------------------------------+
-| **Release designation** | 5.0.0 |
+| **Release designation** | 6.0.0 |
| | |
+--------------------------------------+--------------------------------------+
-| **Release date** | 2017-10-20 |
+| **Release date** | 2018-04-30 |
| | |
+--------------------------------------+--------------------------------------+
-| **Purpose of the delivery** | OPNFV Euphrates release |
+| **Purpose of the delivery** | OPNFV Fraser release |
| | |
+--------------------------------------+--------------------------------------+
Module version changes
~~~~~~~~~~~~~~~~~~~~~~
-This is the first tracked version of the Euphrates release with the Apex
+This is the first tracked version of the Fraser release with the Apex
deployment toolchain. It is based on following upstream versions:
-- OpenStack (Newton release)
+- OpenStack (Pike release)
-- OpenDaylight (Carbon/Nitrogen(master) releases)
+- OpenDaylight (Nitrogen/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 Fraser 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 Fraser 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 Fraser 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
------------
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 Fraser release with the Apex
+ deployment toolchain - ver. 6.0
+- OPNFV Release Notes for the Fraser release with the Apex deployment
+ toolchain - ver. 6.0 (this document)
Known Limitations, Issues and Workarounds
=========================================
| **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 |
+--------------------------------------+--------------------------------------+
| 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 |
+--------------------------------------+--------------------------------------+
References
==========
-For more information on the OPNFV Euphrates release, please see:
+For more information on the OPNFV Fraser release, please see:
-http://wiki.opnfv.org/releases/Euphrates
+http://wiki.opnfv.org/releases/Fraser
:Authors: Tim Rozet (trozet@redhat.com)
:Authors: Dan Radez (dradez@redhat.com)
-:Version: 5.0
+:Version: 6.0
.. 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 Fraser 1.0 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 Pike OpenStack
deployment without any NFV features or SDN controller enabled.
Scenario components and composition
References
==========
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
+For more information on the OPNFV Fraser release, please visit
+http://www.opnfv.org/fraser
.. 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 Fraser 1.0 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 Pike OpenStack
deployment without any NFV features or SDN controller enabled.
Scenario components and composition
References
==========
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
+For more information on the OPNFV Fraser release, please visit
+http://www.opnfv.org/fraser
+++ /dev/null
-.. _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
+++ /dev/null
-.. 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
+++ /dev/null
-.. _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
+++ /dev/null
-.. 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
.. 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 Fraser 1.0 of
deployment with no SDN controller and performance options enabled.
============
============
This scenario is used primarily to demonstrate the performance settings and
-capabilities in Apex. This scenario will deploy a Newton OpenStack
+capabilities in Apex. This scenario will deploy a Pike OpenStack
deployment without any NFV features or SDN controller enabled.
Scenario components and composition
References
==========
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
+For more information on the OPNFV Fraser release, please visit
+http://www.opnfv.org/fraser
+++ /dev/null
-.. _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
+++ /dev/null
-.. 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
-
.. 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 Fraser 1.0 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 Pike OpenStack
deployment with OpenDaylight, and without any NFV features enabled.
Scenario components and composition
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 Fraser release, please visit
+http://www.opnfv.org/fraser
.. 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 Fraser 1.0 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 Pike OpenStack
deployment with OpenDaylight, and without any NFV features enabled.
Scenario components and composition
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 Fraser release, please visit
+http://www.opnfv.org/fraser
.. 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 Fraser 1.0 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
References
==========
-For more information on the OPNFV Euphrates release, please visit
-http://www.opnfv.org/euphrates
+For more information on the OPNFV Fraser release, please visit
+http://www.opnfv.org/fraser
Code Review / apex.git / commitdiff