diff options
author | Tim Rozet <trozet@redhat.com> | 2018-04-25 13:45:31 -0400 |
---|---|---|
committer | Tim Rozet <trozet@redhat.com> | 2018-04-25 18:24:42 -0400 |
commit | 22bc385f5b2e25694699a614268aaad2fdacbb12 (patch) | |
tree | 8a84884ecf5bcc6888c5b836728941a57fedef5c | |
parent | 94ce44fe6e3450a1217ec3838a43049e53da9f6e (diff) |
Updates documentation for Fraser release
Change-Id: I19bfaa5b2778baf458df60a4a53d135e57859e04
Signed-off-by: Tim Rozet <trozet@redhat.com>
22 files changed, 189 insertions, 476 deletions
diff --git a/docs/release/installation/abstract.rst b/docs/release/installation/abstract.rst index 534d8a89..aeef1246 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 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/>. diff --git a/docs/release/installation/architecture.rst b/docs/release/installation/architecture.rst index 70067ed0..1ab7c7fc 100644 --- a/docs/release/installation/architecture.rst +++ b/docs/release/installation/architecture.rst @@ -131,22 +131,22 @@ issues per scenario. The following scenarios correspond to a supported +-------------------------+-------------+---------------+ | 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 | +-------------------------+-------------+---------------+ @@ -170,15 +170,15 @@ issues per scenario. The following scenarios correspond to a supported +-------------------------+-------------+---------------+ | 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 | +-------------------------+-------------+---------------+ diff --git a/docs/release/installation/baremetal.rst b/docs/release/installation/baremetal.rst index 703d1692..d8f90792 100644 --- a/docs/release/installation/baremetal.rst +++ b/docs/release/installation/baremetal.rst @@ -88,7 +88,7 @@ Install Bare Metal Jump Host ``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 diff --git a/docs/release/installation/index.rst b/docs/release/installation/index.rst index 8fb49464..82b9d25c 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: 6.0 Indices and tables ================== diff --git a/docs/release/installation/introduction.rst b/docs/release/installation/introduction.rst index bb220b7d..8dbf8f2f 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 Fraser reference +platform using the Apex installer. The audience is assumed to have a good background in networking and Linux administration. @@ -19,7 +19,7 @@ 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 +(``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 diff --git a/docs/release/installation/references.rst b/docs/release/installation/references.rst index 249da226..935be038 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 Pike Release artifacts <http://www.openstack.org/software/pike>`_ `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 8d441404..9aefa21d 100644 --- a/docs/release/installation/requirements.rst +++ b/docs/release/installation/requirements.rst @@ -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 Fraser Apex RPMs and their 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 6a81bef6..f5b42089 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 00000000..b98b0c19 --- /dev/null +++ b/docs/release/installation/upstream.rst @@ -0,0 +1,107 @@ +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. diff --git a/docs/release/release-notes/release-notes.rst b/docs/release/release-notes/release-notes.rst index 4be2e651..6ddfafc3 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 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 @@ -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 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. @@ -29,14 +29,14 @@ deploy OPNFV using Apex installer. 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 @@ -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 Fraser 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-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 | | | | +--------------------------------------+--------------------------------------+ @@ -74,138 +74,27 @@ Version change 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 ------------ @@ -223,10 +112,10 @@ Software 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 ========================================= @@ -253,18 +142,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,17 +160,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 | +--------------------------------------+--------------------------------------+ @@ -308,10 +182,10 @@ Apex installer. 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 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 0aa72ba0..bc6d39b8 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 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 @@ -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 Fraser release, please visit +http://www.opnfv.org/fraser 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 6889f7d9..8edd29bd 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 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 @@ -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 Fraser release, please visit +http://www.opnfv.org/fraser 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 febf16c1..00000000 --- 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 39083850..00000000 --- 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 699f3915..00000000 --- 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 be0f37d3..00000000 --- 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 index 6437ce1b..beed894e 100644 --- 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 @@ -2,7 +2,7 @@ .. 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. ============ @@ -10,7 +10,7 @@ Introduction ============ 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 @@ -49,6 +49,6 @@ Limitations, Issues and Workarounds 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 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 51cf903f..00000000 --- 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 b75c4355..00000000 --- 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 e5561a79..52530cdd 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 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 @@ -44,14 +44,12 @@ Limitations, Issues and Workarounds 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 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 f04e7c02..932ccc85 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 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 @@ -38,14 +38,12 @@ Limitations, Issues and Workarounds 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 diff --git a/docs/release/scenarios/os-ovn-nofeature-noha/os-ovn-nofeature-noha.rst b/docs/release/scenarios/os-ovn-nofeature-noha/os-ovn-nofeature-noha.rst index a838e4b1..1b2da194 100644 --- a/docs/release/scenarios/os-ovn-nofeature-noha/os-ovn-nofeature-noha.rst +++ b/docs/release/scenarios/os-ovn-nofeature-noha/os-ovn-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 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 @@ -35,6 +35,6 @@ Limitations, Issues and Workarounds 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 |