diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/release/release-notes/release-notes.rst | 424 | ||||
-rw-r--r-- | docs/release/results/index.rst | 5 | ||||
-rwxr-xr-x | docs/testing/developer/devguide/devguide.rst | 6 | ||||
-rwxr-xr-x | docs/testing/developer/devguide/devguide_nsb_prox.rst | 333 | ||||
-rwxr-xr-x | docs/testing/user/userguide/01-introduction.rst | 2 | ||||
-rwxr-xr-x | docs/testing/user/userguide/03-architecture.rst | 25 | ||||
-rw-r--r-- | docs/testing/user/userguide/04-installation.rst | 30 | ||||
-rw-r--r-- | docs/testing/user/userguide/13-nsb-installation.rst | 53 | ||||
-rw-r--r-- | docs/testing/user/userguide/14-nsb-operation.rst | 107 | ||||
-rw-r--r-- | docs/testing/user/userguide/15-list-of-tcs.rst | 6 | ||||
-rw-r--r-- | docs/testing/user/userguide/nsb/nsb-list-of-tcs.rst | 2 |
11 files changed, 526 insertions, 467 deletions
diff --git a/docs/release/release-notes/release-notes.rst b/docs/release/release-notes/release-notes.rst index 457b308ae..4b3f12bcf 100644 --- a/docs/release/release-notes/release-notes.rst +++ b/docs/release/release-notes/release-notes.rst @@ -1,18 +1,12 @@ -======= -License -======= - -OPNFV Fraser release note for Yardstick 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 <https://creativecommons.org/licenses/by/4.0/>. +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 The *Yardstick framework*, the *Yardstick test cases* are open-source software, licensed under the terms of the Apache License, Version 2.0. -======================================= -OPNFV Fraser Release Note for Yardstick -======================================= +======================= +Yardstick Release Notes +======================= .. toctree:: :maxdepth: 2 @@ -27,7 +21,7 @@ OPNFV Fraser Release Note for Yardstick Abstract ======== -This document describes the release note of Yardstick project. +This document compiles the release notes for the Gambia release of OPNFV Yardstick. Version History @@ -36,16 +30,7 @@ Version History | *Date* | *Version* | *Comment* | | | | | +-------------------+-----------+---------------------------------+ -| Jul 2, 2018 | 6.2.1 | Yardstick for Fraser release | -| | | | -+-------------------+-----------+---------------------------------+ -| Jun 29, 2018 | 6.2.0 | Yardstick for Fraser release | -| | | | -+-------------------+-----------+---------------------------------+ -| May 25, 2018 | 6.1.0 | Yardstick for Fraser release | -| | | | -+-------------------+-----------+---------------------------------+ -| April 27, 2018 | 6.0.0 | Yardstick for Fraser release | +| November 9, 2018 | 7.0.0 | Yardstick for Gambia release | | | | | +-------------------+-----------+---------------------------------+ @@ -60,10 +45,10 @@ the methodology in ETSI-ISG NFV-TST001_. The *Yardstick* framework is *installer*, *infrastructure* and *application* independent. -OPNFV Fraser Release +OPNFV Gambia Release ==================== -This Fraser release provides *Yardstick* as a framework for NFVI testing +This Gambia release provides *Yardstick* as a framework for NFVI testing and OPNFV feature testing, automated in the OPNFV CI pipeline, including: * Documentation generated with Sphinx @@ -88,7 +73,7 @@ and OPNFV feature testing, automated in the OPNFV CI pipeline, including: * Yardstick plug-in configuration yaml files, plug-in install/remove scripts -For Fraser release, the *Yardstick framework* is used for the following +For Gambia release, the *Yardstick framework* is used for the following testing: * OPNFV platform testing - generic test cases to measure the categories: @@ -126,19 +111,19 @@ Release Data | **Project** | Yardstick | | | | +--------------------------------+-----------------------+ -| **Repo/tag** | yardstick/opnfv-6.2.0 | +| **Repo/tag** | yardstick/opnfv-7.0.0 | | | | +--------------------------------+-----------------------+ -| **Yardstick Docker image tag** | opnfv-6.2.0 | +| **Yardstick Docker image tag** | opnfv-7.0.0 | | | | +--------------------------------+-----------------------+ -| **Release designation** | Fraser | +| **Release designation** | Gambia 7.0 | | | | +--------------------------------+-----------------------+ -| **Release date** | Jun 29, 2018 | +| **Release date** | November 9, 2018 | | | | +--------------------------------+-----------------------+ -| **Purpose of the delivery** | OPNFV Fraser 6.2.0 | +| **Purpose of the delivery** | OPNFV Gambia 7.0.0 | | | | +--------------------------------+-----------------------+ @@ -157,7 +142,7 @@ Documents Software Deliverables --------------------- - - The Yardstick Docker image: https://hub.docker.com/r/opnfv/yardstick (tag: opnfv-6.2.0) + - The Yardstick Docker image: https://hub.docker.com/r/opnfv/yardstick (tag: opnfv-7.0.0) List of Contexts ^^^^^^^^^^^^^^^^ @@ -183,33 +168,37 @@ List of Contexts List of Runners ^^^^^^^^^^^^^^^ -.. note:: Yardstick Fraser 6.0.0 add two new Runners, "Dynamictp" and "Search". - -+---------------+-------------------------------------------------------+ -| **Runner** | **Description** | -| | | -+---------------+-------------------------------------------------------+ -| *Arithmetic* | Steps every run arithmetically according to specified | -| | input value | -| | | -+---------------+-------------------------------------------------------+ -| *Duration* | Runs for a specified period of time | -| | | -+---------------+-------------------------------------------------------+ -| *Iteration* | Runs for a specified number of iterations | -| | | -+---------------+-------------------------------------------------------+ -| *Sequence* | Selects input value to a scenario from an input file | -| | and runs all entries sequentially | -| | | -+---------------+-------------------------------------------------------+ -| **Dynamictp** | A runner that searches for the max throughput with | -| | binary search | -| | | -+---------------+-------------------------------------------------------+ -| **Search** | A runner that runs a specific time before it returns | -| | | -+---------------+-------------------------------------------------------+ +.. note:: Yardstick Gambia 7.0.0 adds 1 new Runner, "IterationIPC". + ++----------------+-------------------------------------------------------+ +| **Runner** | **Description** | +| | | ++----------------+-------------------------------------------------------+ +| *Arithmetic* | Steps every run arithmetically according to specified | +| | input value | +| | | ++----------------+-------------------------------------------------------+ +| *Duration* | Runs for a specified period of time | +| | | ++----------------+-------------------------------------------------------+ +| *Iteration* | Runs for a specified number of iterations | +| | | ++----------------+-------------------------------------------------------+ +| *IterationIPC* | Runs a configurable number of times before it | +| | returns. Each iteration has a configurable timeout. | +| | | ++----------------+-------------------------------------------------------+ +| *Sequence* | Selects input value to a scenario from an input file | +| | and runs all entries sequentially | +| | | ++----------------+-------------------------------------------------------+ +| *Dynamictp* | A runner that searches for the max throughput with | +| | binary search | +| | | ++----------------+-------------------------------------------------------+ +| *Search* | A runner that runs a specific time before it returns | +| | | ++----------------+-------------------------------------------------------+ List of Scenarios @@ -280,19 +269,15 @@ List of Scenarios New Test cases -------------- -.. note:: Yardstick Fraser 6.1.0 added two new test cases, "TC092" and "TC093". +.. note:: Yardstick Gambia 7.0.0 adds no new test cases. * Generic NFVI test cases - * OPNFV_YARDSTICK_TCO84 - SPEC CPU 2006 for VM + * (e.g.) OPNFV_YARDSTICK_TCO84 - SPEC CPU 2006 for VM * HA Test cases - * OPNFV_YARDSTICK_TC087 - SDN Controller resilience in non-HA configuration - * OPNFV_YARDSTICK_TC090 - Control node Openstack service down - database instance - * OPNFV_YARDSTICK_TC091 - Control node Openstack service down - heat-api - * OPNFV_YARDSTICK_TC092 - SDN Controller resilience in HA configuration - * OPNFV_YARDSTICK_TC093 - SDN Vswitch resilience in non-HA or HA configuration + * (e.g.) OPNFV_YARDSTICK_TC093 - SDN Vswitch resilience in non-HA or HA configuration Version Change @@ -301,22 +286,23 @@ Version Change Module Version Changes ---------------------- -This is the sixth tracked release of Yardstick. It is based on following +This is the seventh tracked release of Yardstick. It is based on following upstream versions: -- OpenStack Pike +- OpenStack Queens - OpenDayLight Oxygen Document Version Changes ------------------------ -This is the sixth tracked version of the Yardstick framework in OPNFV. +This is the seventh tracked version of the Yardstick framework in OPNFV. It includes the following documentation updates: -- Yardstick User Guide: add "network service benchmarking(NSB)" chapter; - add "Yardstick - NSB Testing -Installation" chapter; add "Yardstick API" chapter; - add "Yardstick user interface" chapter; Update Yardstick installation chapter; +- Yardstick User Guide: + + - Remove vTC chapter; + - Yardstick Developer Guide - Yardstick Release Notes for Yardstick: this document @@ -324,49 +310,49 @@ It includes the following documentation updates: Feature additions ----------------- -- Plugin-based test cases support Heat context -- SR-IOV support for the Heat context -- Support using existing network in Heat context -- Support running test cases with existing VNFs/without destroying VNF in Heat context -- Add vFW scale-up template -- Improvements of unit tests and gating -- GUI improvement about passing parameters +- Simplify Yardstick installation to use a single ansible playbook (nsb_setup.yaml).... +- Spirent support. +- vEPC testcases. +- Agnostic VNF tests cases for reuse of standard RFC-2544 test case. +- PROX enhancements and the addition of Standalone test case using SRIOV and + OVS-DPDK. +- Ixia enhancements for vBNG and PPPoE traffic. +- Improvements of unit tests and gating. +- Add DPDK pktgen traffic generator. +- Kubernetes context enhancements. +- Kubernetes sample test cases of fio and lmbench added. Scenario Matrix =============== -For Fraser 6.0.0, Yardstick was tested on the following scenarios: - -+-------------------------+------+---------+----------+------+------+-------+ -| Scenario | Apex | Compass | Fuel-arm | Fuel | Joid | Daisy | -+=========================+======+=========+==========+======+======+=======+ -| os-nosdn-nofeature-noha | X | X | | | X | | -+-------------------------+------+---------+----------+------+------+-------+ -| os-nosdn-nofeature-ha | X | X | X | X | X | X | -+-------------------------+------+---------+----------+------+------+-------+ -| os-nosdn-bar-noha | X | X | | | | | -+-------------------------+------+---------+----------+------+------+-------+ -| os-nosdn-bar-ha | X | | | | | | -+-------------------------+------+---------+----------+------+------+-------+ -| os-odl-bgpvpn-ha | X | | | | | | -+-------------------------+------+---------+----------+------+------+-------+ -| os-nosdn-calipso-noha | X | | | | | | -+-------------------------+------+---------+----------+------+------+-------+ -| os-nosdn-kvm-ha | | X | | | | | -+-------------------------+------+---------+----------+------+------+-------+ -| os-odl_l3-nofeature-ha | | X | | | | | -+-------------------------+------+---------+----------+------+------+-------+ -| os-odl-sfc-ha | | X | | | | | -+-------------------------+------+---------+----------+------+------+-------+ -| os-odl-nofeature-ha | | | | X | | X | -+-------------------------+------+---------+----------+------+------+-------+ -| os-nosdn-ovs-ha | | | | X | | | -+-------------------------+------+---------+----------+------+------+-------+ -| k8-nosdn-nofeature-ha | | X | | | | | -+-------------------------+------+---------+----------+------+------+-------+ -| k8-nosdn-stor4nfv-noha | | X | | | | | -+-------------------------+------+---------+----------+------+------+-------+ +For Gambia 7.0.0, Yardstick was tested on the following scenarios: + ++-------------------------+------+---------+----------+------+ +| Scenario | Apex | Compass | Fuel-arm | Fuel | ++=========================+======+=========+==========+======+ +| os-nosdn-nofeature-noha | X | | | | ++-------------------------+------+---------+----------+------+ +| os-nosdn-nofeature-ha | X | | | | ++-------------------------+------+---------+----------+------+ +| os-odl-bgpvpn-noha | X | | | | ++-------------------------+------+---------+----------+------+ +| os-nosdn-calipso-noha | X | | | | ++-------------------------+------+---------+----------+------+ +| os-nosdn-kvm-ha | | X | | | ++-------------------------+------+---------+----------+------+ +| os-odl-nofeature-ha | | | X | X | ++-------------------------+------+---------+----------+------+ +| os-odl-sfc-noha | X | | | | ++-------------------------+------+---------+----------+------+ +| os-nosdn-ovs-ha | | | | X | ++-------------------------+------+---------+----------+------+ +| k8-nosdn-nofeature-ha | | X | | | ++-------------------------+------+---------+----------+------+ +| k8-nosdn-stor4nfv-noha | | X | | | ++-------------------------+------+---------+----------+------+ +| k8-nosdn-stor4nfv-ha | | X | | | ++-------------------------+------+---------+----------+------+ Test results @@ -376,19 +362,6 @@ Test results are available in: - jenkins logs on CI: https://build.opnfv.org/ci/view/yardstick/ -The reporting pages can be found at: - -+---------------+----------------------------------------------------------------------------------+ -| apex | http://testresults.opnfv.org/reporting/fraser/yardstick/status-apex.html | -+---------------+----------------------------------------------------------------------------------+ -| compass | http://testresults.opnfv.org/reporting/fraser/yardstick/status-compass.html | -+---------------+----------------------------------------------------------------------------------+ -| fuel\@x86 | http://testresults.opnfv.org/reporting/fraser/yardstick/status-fuel@x86.html | -+---------------+----------------------------------------------------------------------------------+ -| fuel\@aarch64 | http://testresults.opnfv.org/reporting/fraser/yardstick/status-fuel@aarch64.html | -+---------------+----------------------------------------------------------------------------------+ -| joid | http://testresults.opnfv.org/reporting/fraser/yardstick/status-joid.html | -+---------------+----------------------------------------------------------------------------------+ Known Issues/Faults ------------------- @@ -397,214 +370,65 @@ Known Issues/Faults Corrected Faults ---------------- -Fraser 6.2.1: +Gambia 7.0.0: +--------------------+--------------------------------------------------------------------------+ | **JIRA REFERENCE** | **DESCRIPTION** | +====================+==========================================================================+ -| YARDSTICK-1147 | Fix ansible scripts for running in container | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1157 | Bug Fix: correct the file path to build docker file | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1276 | Bugfix: docker build failed | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1280 | Bugfix: uwsgi config file yardstick.ini output error | -+--------------------+--------------------------------------------------------------------------+ - -Fraser 6.2.0: - -+--------------------+--------------------------------------------------------------------------+ -| **JIRA REFERENCE** | **DESCRIPTION** | -+====================+==========================================================================+ -| YARDSTICK-1246 | Update pmd/lcore mask for OVS-DPDK context | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-837 | Move tests: unit/network_services/{lib/,collector/,*.py} | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1144 | Correctly set PYTHONPATH in Dockerfile | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1205 | Set "cmd2" library to version 0.8.6 | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1204 | Bump oslo.messaging version to 5.36.0 | +| YARDSTICK-1137 | Fix CLI argument handling in nsb_setup.sh | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1210 | Remove __init__ method overriding in HeatContextTestCase | +| YARDSTICK-1220 | Get stats for multiple port simultaneously | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1189 | Error when adding SR-IOV interfaces in SR-IOV context | +| YARDSTICK-1260 | Added missing functionality to start VM and access it using SSH keys | +| | in Standalone contexts. | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1214 | Remove AnsibleCommon class method mock | +| YARDSTICK-1298 | Allows for in-line overriding/modification of traffic profile variables | +| | from the testcase file. | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1159 | Add --hwlb options as a command line argument for SampleVNF | +| YARDSTICK-1368 | Updated existing test cases in Yardstick to minimize changes done | +| | manually to run standalone tests for Trex. | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1203 | Add scale out TCs with availability zone support | +| YARDSTICK-1389 | Add status filed for RFC2544 TC iterations | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1167 | Do not start collectd twice when SampleVNF is running on Baremetal | +| YARDSTICK-1395 | Update 'configure_uwsgi' role to work in baremetal/container modes. | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1188 | Add "host_name_separator" variable to Context class | +| YARDSTICK-1402 | Change IP assignment for VM to static for standalone context | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1112 | MQ startup process refactor | +| YARDSTICK-1404 | CPU Utilization for VNF and traffic generator are now graphed on Grafana | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1229 | Cleanup BaseMonitor unit tests | +| YARDSTICK-1411 | Fix Yardstick Docker image ARM build | +--------------------+--------------------------------------------------------------------------+ -| - | Configure ACL via static file | +| YARDSTICK-1414 | Update the pinned sampleVNF version to use a commit instead of a branch | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1191 | Use TRex release v2.41 to support both x86 and aarch64 | +| YARDSTICK-1418 | NSB PROX NFVi test now stops after reaching expected precision | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1106 | Add IxNetwork API Python Binding package | +| YARDSTICK-1457 | Fix influxdb "field type conflict" error | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1224 | Cleanup TestYardstickNSCli class | +| YARDSTICK-1458 | Update Grafana to display "real-time" data instead of historical data. | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1225 | Remove print out of logger exception in TestUtils | +| YARDSTICK-1462 | NSB: Add OvS 2.8.1 support in SA context | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1194 | Add "duration" parameter to test case definition | +| YARDSTICK-1492 | Make OvS server to listen on TCP | +--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1209 | Remove instantiated contexts in "test_task" | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1192 | Standalone XML machine type is not longer valid | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1197 | Refactor RFC2455 TRex traffic profile injection | -+--------------------+--------------------------------------------------------------------------+ -| - | Fix "os.path" mock problems during tests | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1218 | Refactor "utils.parse_ini_file" testing | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1179 | Start nginx and uwsgi servicies only in not container mode | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1177 | Install dependencies: bare-metal, standalone | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1126 | Migrate install.sh script to ansible | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1146 | Fix nsb_setup.sh script | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1247 | NSB setup inventory name changed | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1116 | Changed IxNextgen library load in IXIA RFC2544 traffic generator call. | -+--------------------+--------------------------------------------------------------------------+ -| - | Corrected scale-up command line arguments | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-878 | OpenStack client replacement | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1222 | Bugfix: HA kill process recovery has a conflict | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1139 | Add "os_cloud_config" as a new context flag parameter | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1255 | Extended Context class with get_physical_nodes functionality | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1244 | NSB NFVi BNG test fails to run - stops after one step | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1219 | Decrease Sampling interval | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1101 | NSB NFVi PROX BNG losing many packets | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1217 | Fix NSB NfVi support for 25 and 40Gbps | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1185 | NSB Topology fix for Prox 4 port test case | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-966 | Convert SLA asserts to raises | +| YARDSTICK-1493 | The RX queues number is hard-codded and cannot be changed | +--------------------+--------------------------------------------------------------------------+ -Fraser 6.1.0: - -+--------------------+--------------------------------------------------------------------------+ -| **JIRA REFERENCE** | **DESCRIPTION** | -+====================+==========================================================================+ -| YARDSTICK-995 | Test case spec for SDN Virtual Switch resilience | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1097 | Add pod.yaml file for APEX installer | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1122 | Remove unused code in SampleVNF | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1125 | Update samples/test_suite.yaml | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1132 | Document for Euphrates test case results | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1138 | Support Restart Operation | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1142 | start_service script fails to start openvswitch service in centos distro | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1165 | Bugfix: openrc api dump should be safe_dump | -+--------------------+--------------------------------------------------------------------------+ - -Fraser 6.0.0: - -+--------------------+--------------------------------------------------------------------------+ -| **JIRA REFERENCE** | **DESCRIPTION** | -+====================+==========================================================================+ -| YARDSTICK-831 | tc053 kill haproxy wrong | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-842 | load image fails when there's cirros image exist | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-857 | tc006 failed due to volume attached to different location "/dev/vdc" | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-874 | Specify supported architecture for Ubuntu backports repository | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-875 | Check if multiverse repository is available in Ubuntu | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-893 | Fix proxy env handling and ansible multinode support | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-899 | Variable local_iface_name is read before it is set | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-900 | Section in "upload_yardstick_image.yml" invalid | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-911 | Remove 'inconsistent-return-statements' from Pylint checks | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-989 | Yardstick real-time influxdb KPI reporting regressions | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-994 | NSB set-up build script for baremetal broken | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-996 | Error in address input format in "_ip_range_action_partial" | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1003 | Prox vnf descriptor cleanup for tg and vnf | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1006 | Ansible destroy script will fail if vm has already been undefined | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1012 | constants: fix pylint warnings for OSError | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1014 | Remove unused args in | -| | network_services.traffic_profile.ixia_rfc2544.IXIARFC2544Profile | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1016 | Allow vm to access outside world through default gateway | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1019 | For 'qemu-img version 2.10.1' unit 'MB' is not acceptable ansible script | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1021 | NSB: All Sample VNF test cases timeout after 1 hour of execution | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1036 | Prox: Addition of storage of extra counters for Grafana | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1038 | Missing file which is described in the operation_conf.yaml | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1047 | Error in string format in HeatTemplateError message | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1056 | yardstick report command print error when run test case | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1059 | Reduce the log level if TRex client is no connected | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1073 | Error when retrieving "options" section in "scenario" | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1080 | Running Test Case in Latest Yardstick Docker Image shows Error | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1082 | tc043,tc055, tc063, tc075, pass wrong node name in the ci scenario yaml | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1102 | Don't hide exception traceback from Task.start() | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1107 | bad exception traceback print due to atexit_handler | -+--------------------+--------------------------------------------------------------------------+ -| YARDSTICK-1120 | HA test case tc050 should start monitor before attack | -+--------------------+--------------------------------------------------------------------------+ -Fraser 6.0.0 known restrictions/issues +Gambia 7.0.0 known restrictions/issues ====================================== -+-----------+-----------+----------------------------------------------+ -| Installer | Scenario | Issue | -+===========+===========+==============================================+ -| | | | -+-----------+-----------+----------------------------------------------+ ++-----------+-----------------------+------------------+ +| Installer | Scenario | Issue | ++===========+=======================+==================+ +| apex | os-ovn-nofeature-ha | YARDSTICK-1517 | ++-----------+-----------------------+------------------+ Useful links ============ - wiki project page: https://wiki.opnfv.org/display/yardstick/Yardstick - - wiki Yardstick Fraser release planing page: https://wiki.opnfv.org/display/yardstick/Release+Fraser + - wiki Yardstick Gambia release planning page: https://wiki.opnfv.org/display/yardstick/Release+Gambia - Yardstick repo: https://git.opnfv.org/yardstick @@ -612,4 +436,4 @@ Useful links - Yardstick grafana dashboard: http://testresults.opnfv.org/grafana/ - - Yardstick IRC chanel: #opnfv-yardstick + - Yardstick IRC channel: #opnfv-yardstick diff --git a/docs/release/results/index.rst b/docs/release/results/index.rst index 63445fd1a..30cf62284 100644 --- a/docs/release/results/index.rst +++ b/docs/release/results/index.rst @@ -15,3 +15,8 @@ Yardstick test results .. include:: ./overview.rst .. include:: ./results.rst .. include:: ./euphrates_fraser_comparison.rst + +.. include:: ./yardstick-opnfv-ha.rst +.. include:: ./yardstick-opnfv-kvm.rst +.. include:: ./yardstick-opnfv-parser.rst + diff --git a/docs/testing/developer/devguide/devguide.rst b/docs/testing/developer/devguide/devguide.rst index 76ed7c651..2065f6e0d 100755 --- a/docs/testing/developer/devguide/devguide.rst +++ b/docs/testing/developer/devguide/devguide.rst @@ -52,9 +52,9 @@ Where can I find some help to start? This guide is made for you. You can have a look at the `user guide`_. There are also references on documentation, video tutorials, tips in the -project `wiki page`_. You can also directly contact us by mail with [Yardstick] -prefix in the subject at opnfv-tech-discuss@lists.opnfv.org or on the IRC chan -#opnfv-yardstick. +project `wiki page`_. You can also directly contact us by mail with +``#yardstick`` or ``[yardstick]`` prefix in the subject at +``opnfv-tech-discuss@lists.opnfv.org`` or on the IRC channel ``#opnfv-yardstick``. Yardstick developer areas diff --git a/docs/testing/developer/devguide/devguide_nsb_prox.rst b/docs/testing/developer/devguide/devguide_nsb_prox.rst index 582668bc5..be2b5be61 100755 --- a/docs/testing/developer/devguide/devguide_nsb_prox.rst +++ b/docs/testing/developer/devguide/devguide_nsb_prox.rst @@ -13,7 +13,8 @@ optimal system architectures and configurations. Prerequisites ============= -In order to integrate PROX tests into NSB, the following prerequisites are required. +In order to integrate PROX tests into NSB, the following prerequisites are +required. .. _`dpdk wiki page`: https://www.dpdk.org/ .. _`yardstick wiki page`: https://wiki.opnfv.org/display/yardstick/ @@ -159,11 +160,13 @@ A NSB Prox test is composed of the following components :- ``tc_prox_heat_context_vpe-4.yaml``. This file describes the components of the test, in the case of openstack the network description and server descriptions, in the case of baremetal the hardware - description location. It also contains the name of the Traffic Generator, the SUT config file - and the traffic profile description, all described below. See nsb-test-description-label_ + description location. It also contains the name of the Traffic Generator, + the SUT config file and the traffic profile description, all described below. + See nsb-test-description-label_ -* Traffic Profile file. Example ``prox_binsearch.yaml``. This describes the packet size, tolerated - loss, initial line rate to start traffic at, test interval etc See nsb-traffic-profile-label_ +* Traffic Profile file. Example ``prox_binsearch.yaml``. This describes the + packet size, tolerated loss, initial line rate to start traffic at, test + interval etc See nsb-traffic-profile-label_ * Traffic Generator Config file. Usually called ``gen_<test>-<ports>.cfg``. @@ -235,7 +238,8 @@ show you how to understand the test description file. Now let's examine the components of the file in detail 1. ``traffic_profile`` - This specifies the traffic profile for the - test. In this case ``prox_binsearch.yaml`` is used. See nsb-traffic-profile-label_ + test. In this case ``prox_binsearch.yaml`` is used. See + nsb-traffic-profile-label_ 2. ``topology`` - This is either ``prox-tg-topology-1.yaml`` or ``prox-tg-topology-2.yaml`` or ``prox-tg-topology-4.yaml`` @@ -330,11 +334,11 @@ This describes the details of the traffic flow. In this case :alt: NSB PROX Traffic Profile -1. ``name`` - The name of the traffic profile. This name should match the name specified in the - ``traffic_profile`` field in the Test Description File. +1. ``name`` - The name of the traffic profile. This name should match the name + specified in the ``traffic_profile`` field in the Test Description File. -2. ``traffic_type`` - This specifies the type of traffic pattern generated, This name matches - class name of the traffic generator See:: +2. ``traffic_type`` - This specifies the type of traffic pattern generated, + This name matches class name of the traffic generator. See:: network_services/traffic_profile/prox_binsearch.py class ProxBinSearchProfile(ProxProfile) @@ -704,15 +708,22 @@ Now let's examine the components of the file in detail physical core improves performance, however sometimes it is optimal to move task to a separate core. This is best decided by checking performance. - c. ``mode=lat`` - Specifies the action carried out by this task on this core. Supported modes are: acl, - classify, drop, gredecap, greencap, ipv6_decap, ipv6_encap, l2fwd, lbnetwork, lbpos, lbqinq, nop, - police, qinqdecapv4, qinqencapv4, qos, routing, impair, lb5tuple, mirror, unmpls, tagmpls, - nat, decapnsh, encapnsh, gen, genl4 and lat. This task(0) per core(3) receives packets on port. - d. ``rx port=p0`` - The port to receive packets on ``Port 0``. Core 4 will receive packets on ``Port 1``. - e. ``lat pos=42`` - Describes where to put a 4-byte timestamp in the packet. Note that the packet length should - be longer than ``lat pos`` + 4 bytes to avoid truncation of the timestamp. It defines where the timestamp is - to be read from. Note that the SUT workload might cause the position of the timestamp to change - (i.e. due to encapsulation). + c. ``mode=lat`` - Specifies the action carried out by this task on this + core. + Supported modes are: ``acl``, ``classify``, ``drop``, ``gredecap``, + ``greencap``, ``ipv6_decap``, ``ipv6_encap``, ``l2fwd``, ``lbnetwork``, + ``lbpos``, ``lbqinq``, ``nop``, ``police``, ``qinqdecapv4``, + ``qinqencapv4``, ``qos``, ``routing``, ``impair``, ``lb5tuple``, + ``mirror``, ``unmpls``, ``tagmpls``, ``nat``, ``decapnsh``, ``encapnsh``, + ``gen``, ``genl4`` and ``lat``. This task(0) per core(3) receives packets + on port. + d. ``rx port=p0`` - The port to receive packets on ``Port 0``. Core 4 will + receive packets on ``Port 1``. + e. ``lat pos=42`` - Describes where to put a 4-byte timestamp in the packet. + Note that the packet length should be longer than ``lat pos`` + 4 bytes + to avoid truncation of the timestamp. It defines where the timestamp is + to be read from. Note that the SUT workload might cause the position of + the timestamp to change (i.e. due to encapsulation). .. _nsb-sut-generator-label: @@ -720,7 +731,8 @@ Now let's examine the components of the file in detail ------------------------------- This section will describes the SUT(VNF) config file. This is the same for both -baremetal and heat. See this example of ``handle_l2fwd_multiflow-2.cfg`` to explain the options. +baremetal and heat. See this example of ``handle_l2fwd_multiflow-2.cfg`` to +explain the options. .. image:: images/PROX_Handle_2port_cfg.png :width: 1400px @@ -730,13 +742,15 @@ See `prox options`_ for details Now let's examine the components of the file in detail -1. ``[eal options]`` - same as the Generator config file. This specified the EAL (Environmental Abstraction Layer) - options. These are default values and are not changed. - See `dpdk wiki page`_. +1. ``[eal options]`` - same as the Generator config file. This specified the + EAL (Environmental Abstraction Layer) options. These are default values and + are not changed. See `dpdk wiki page`_. -2. ``[port 0]`` - This section describes the DPDK Port. The number following the keyword ``port`` usually refers to the DPDK Port Id. usually starting from ``0``. - Because you can have multiple ports this entry usually repeated. Eg. For a 2 port setup ``[port0]`` and ``[port 1]`` and for a 4 port setup ``[port 0]``, ``[port 1]``, - ``[port 2]`` and ``[port 3]``:: +2. ``[port 0]`` - This section describes the DPDK Port. The number following + the keyword ``port`` usually refers to the DPDK Port Id. usually starting + from ``0``. Because you can have multiple ports this entry usually + repeated. E.g. For a 2 port setup ``[port0]`` and ``[port 1]`` and for a 4 + port setup ``[port 0]``, ``[port 1]``, ``[port 2]`` and ``[port 3]``:: [port 0] name=if0 @@ -745,10 +759,14 @@ Now let's examine the components of the file in detail tx desc=2048 promiscuous=yes - a. In this example ``name =if0`` assigned the name ``if0`` to the port. Any name can be assigned to a port. - b. ``mac=hardware`` sets the MAC address assigned by the hardware to data from this port. - c. ``rx desc=2048`` sets the number of available descriptors to allocate for receive packets. This can be changed and can effect performance. - d. ``tx desc=2048`` sets the number of available descriptors to allocate for transmit packets. This can be changed and can effect performance. + a. In this example ``name =if0`` assigned the name ``if0`` to the port. Any + name can be assigned to a port. + b. ``mac=hardware`` sets the MAC address assigned by the hardware to data + from this port. + c. ``rx desc=2048`` sets the number of available descriptors to allocate + for receive packets. This can be changed and can effect performance. + d. ``tx desc=2048`` sets the number of available descriptors to allocate + for transmit packets. This can be changed and can effect performance. e. ``promiscuous=yes`` this enables promiscuous mode for this port. 3. ``[defaults]`` - Here default operations and settings can be over written.:: @@ -757,35 +775,46 @@ Now let's examine the components of the file in detail mempool size=8K memcache size=512 - a. In this example ``mempool size=8K`` the number of mbufs per task is altered. Altering this value could effect performance. See `prox options`_ for details. - b. ``memcache size=512`` - number of mbufs cached per core, default is 256 this is the cache_size. Altering this value could effect performance. + a. In this example ``mempool size=8K`` the number of mbufs per task is + altered. Altering this value could effect performance. See + `prox options`_ for details. + b. ``memcache size=512`` - number of mbufs cached per core, default is 256 + this is the cache_size. Altering this value could affect performance. -4. ``[global]`` - Here application wide setting are supported. Things like application name, start time, duration and memory configurations can be set here. +4. ``[global]`` - Here application wide setting are supported. Things like + application name, start time, duration and memory configurations can be set + here. In this example.:: [global] start time=5 name=Basic Gen - a. ``start time=5`` Time is seconds after which average stats will be started. + a. ``start time=5`` Time is seconds after which average stats will be + started. b. ``name=Handle L2FWD Multiflow (2x)`` Name of the configuration. -5. ``[core 0]`` - This core is designated the master core. Every Prox application must have a master core. The master mode must be assigned to +5. ``[core 0]`` - This core is designated the master core. Every Prox + application must have a master core. The master mode must be assigned to exactly one task, running alone on one core.:: [core 0] mode=master -6. ``[core 1]`` - This describes the activity on core 1. Cores can be configured by means of a set of [core #] sections, where # represents either: +6. ``[core 1]`` - This describes the activity on core 1. Cores can be + configured by means of a set of [core #] sections, where # represents + either: - a. an absolute core number: e.g. on a 10-core, dual socket system with hyper-threading, - cores are numbered from 0 to 39. + a. an absolute core number: e.g. on a 10-core, dual socket system with + hyper-threading, cores are numbered from 0 to 39. - b. PROX allows a core to be identified by a core number, the letter 's', and a socket number. - However NSB PROX is hardware agnostic (physical and virtual configurations are the same) it - is advisable no to use physical core numbering. + b. PROX allows a core to be identified by a core number, the letter 's', + and a socket number. However NSB PROX is hardware agnostic (physical and + virtual configurations are the same) it is advisable no to use physical + core numbering. - Each core can be assigned with a set of tasks, each running one of the implemented packet processing modes.:: + Each core can be assigned with a set of tasks, each running one of the + implemented packet processing modes.:: [core 1] name=none @@ -796,20 +825,33 @@ Now let's examine the components of the file in detail tx port=if1 a. ``name=none`` - No name assigned to the core. - b. ``task=0`` - Each core can run a set of tasks. Starting with ``0``. Task 1 can be defined later in this core or - can be defined in another ``[core 1]`` section with ``task=1`` later in configuration file. Sometimes running - multiple task related to the same packet on the same physical core improves performance, however sometimes it - is optimal to move task to a separate core. This is best decided by checking performance. - c. ``mode=l2fwd`` - Specifies the action carried out by this task on this core. Supported modes are: acl, - classify, drop, gredecap, greencap, ipv6_decap, ipv6_encap, l2fwd, lbnetwork, lbpos, lbqinq, nop, - police, qinqdecapv4, qinqencapv4, qos, routing, impair, lb5tuple, mirror, unmpls, tagmpls, - nat, decapnsh, encapnsh, gen, genl4 and lat. This code does ``l2fwd`` .. ie it does the L2FWD. - - d. ``dst mac=@@tester_mac1`` - The destination mac address of the packet will be set to the MAC address of ``Port 1`` of destination device. (The Traffic Generator/Verifier) - e. ``rx port=if0`` - This specifies that the packets are received from ``Port 0`` called if0 - f. ``tx port=if1`` - This specifies that the packets are transmitted to ``Port 1`` called if1 - - If this example we receive a packet on core on a port, carry out operation on the packet on the core and transmit it on on another port still using the same task on the same core. + b. ``task=0`` - Each core can run a set of tasks. Starting with ``0``. + Task 1 can be defined later in this core or can be defined in another + ``[core 1]`` section with ``task=1`` later in configuration file. + Sometimes running multiple task related to the same packet on the same + physical core improves performance, however sometimes it is optimal to + move task to a separate core. This is best decided by checking + performance. + c. ``mode=l2fwd`` - Specifies the action carried out by this task on this + core. Supported modes are: ``acl``, ``classify``, ``drop``, + ``gredecap``, ``greencap``, ``ipv6_decap``, ``ipv6_encap``, ``l2fwd``, + ``lbnetwork``, ``lbpos``, ``lbqinq``, ``nop``, ``police``, + ``qinqdecapv4``, ``qinqencapv4``, ``qos``, ``routing``, ``impair``, + ``lb5tuple``, ``mirror``, ``unmpls``, ``tagmpls``, ``nat``, + ``decapnsh``, ``encapnsh``, ``gen``, ``genl4`` and ``lat``. This code + does ``l2fwd``. i.e. it does the L2FWD. + + d. ``dst mac=@@tester_mac1`` - The destination mac address of the packet + will be set to the MAC address of ``Port 1`` of destination device. + (The Traffic Generator/Verifier) + e. ``rx port=if0`` - This specifies that the packets are received from + ``Port 0`` called if0 + f. ``tx port=if1`` - This specifies that the packets are transmitted to + ``Port 1`` called if1 + + In this example we receive a packet on core on a port, carry out operation + on the packet on the core and transmit it on on another port still using + the same task on the same core. On some implementation you may wish to use multiple tasks, like this.:: @@ -829,15 +871,22 @@ Now let's examine the components of the file in detail tx port=if0 drop=no - In this example you can see Core 1/Task 0 called ``rx_task`` receives the packet from if0 and perform the l2fwd. However instead of sending the packet to a - port it sends it to a core see ``tx cores=1t1``. In this case it sends it to Core 1/Task 1. + In this example you can see Core 1/Task 0 called ``rx_task`` receives the + packet from if0 and perform the l2fwd. However instead of sending the + packet to a port it sends it to a core see ``tx cores=1t1``. In this case it + sends it to Core 1/Task 1. - Core 1/Task 1 called ``l2fwd_if0``, receives the packet, not from a port but from the ring. See ``rx ring=yes``. It does not perform any operation on the packet See ``mode=none`` - and sends the packets to ``if0`` see ``tx port=if0``. + Core 1/Task 1 called ``l2fwd_if0``, receives the packet, not from a port but + from the ring. See ``rx ring=yes``. It does not perform any operation on the + packet See ``mode=none`` and sends the packets to ``if0`` see + ``tx port=if0``. - It is also possible to implement more complex operations be chaining multiple operations in sequence and using rings to pass packets from one core to another. + It is also possible to implement more complex operations by chaining + multiple operations in sequence and using rings to pass packets from one + core to another. - In thus example we show a Broadband Network Gateway (BNG) with Quality of Service (QoS). Communication from task to task is via rings. + In this example, we show a Broadband Network Gateway (BNG) with Quality of + Service (QoS). Communication from task to task is via rings. .. image:: images/PROX_BNG_QOS.png :width: 1000px @@ -848,26 +897,36 @@ Now let's examine the components of the file in detail .. _baremetal-config-label: -This is required for baremetal testing. It describes the IP address of the various ports, the Network devices drivers and MAC addresses and the network +This is required for baremetal testing. It describes the IP address of the +various ports, the Network devices drivers and MAC addresses and the network configuration. -In this example we will describe a 2 port configuration. This file is the same for all 2 port NSB Prox tests on the same platforms/configuration. +In this example we will describe a 2 port configuration. This file is the same +for all 2 port NSB Prox tests on the same platforms/configuration. .. image:: images/PROX_Baremetal_config.png :width: 1000px :alt: NSB PROX Yardstick Config -Now lets describe the sections of the file. - - 1. ``TrafficGen`` - This section describes the Traffic Generator node of the test configuration. The name of the node ``trafficgen_1`` must match the node name - in the ``Test Description File for Baremetal`` mentioned earlier. The password attribute of the test needs to be configured. All other parameters - can remain as default settings. - 2. ``interfaces`` - This defines the DPDK interfaces on the Traffic Generator. - 3. ``xe0`` is DPDK Port 0. ``lspci`` and `` ./dpdk-devbind.py -s`` can be used to provide the interface information. ``netmask`` and ``local_ip`` should not be changed - 4. ``xe1`` is DPDK Port 1. If more than 2 ports are required then ``xe1`` section needs to be repeated and modified accordingly. - 5. ``vnf`` - This section describes the SUT of the test configuration. The name of the node ``vnf`` must match the node name in the - ``Test Description File for Baremetal`` mentioned earlier. The password attribute of the test needs to be configured. All other parameters - can remain as default settings +Now let's describe the sections of the file. + + 1. ``TrafficGen`` - This section describes the Traffic Generator node of the + test configuration. The name of the node ``trafficgen_1`` must match the + node name in the ``Test Description File for Baremetal`` mentioned + earlier. The password attribute of the test needs to be configured. All + other parameters can remain as default settings. + 2. ``interfaces`` - This defines the DPDK interfaces on the Traffic + Generator. + 3. ``xe0`` is DPDK Port 0. ``lspci`` and ``./dpdk-devbind.py -s`` can be used + to provide the interface information. ``netmask`` and ``local_ip`` should + not be changed + 4. ``xe1`` is DPDK Port 1. If more than 2 ports are required then ``xe1`` + section needs to be repeated and modified accordingly. + 5. ``vnf`` - This section describes the SUT of the test configuration. The + name of the node ``vnf`` must match the node name in the + ``Test Description File for Baremetal`` mentioned earlier. The password + attribute of the test needs to be configured. All other parameters can + remain as default settings 6. ``interfaces`` - This defines the DPDK interfaces on the SUT 7. ``xe0`` - Same as 3 but for the ``SUT``. 8. ``xe1`` - Same as 4 but for the ``SUT`` also. @@ -877,11 +936,13 @@ Now lets describe the sections of the file. *Grafana Dashboard* ------------------- -The grafana dashboard visually displays the results of the tests. The steps required to produce a grafana dashboard are described here. +The grafana dashboard visually displays the results of the tests. The steps +required to produce a grafana dashboard are described here. .. _yardstick-config-label: - a. Configure ``yardstick`` to use influxDB to store test results. See file ``/etc/yardstick/yardstick.conf``. + a. Configure ``yardstick`` to use influxDB to store test results. See file + ``/etc/yardstick/yardstick.conf``. .. image:: images/PROX_Yardstick_config.png :width: 1000px @@ -890,10 +951,12 @@ The grafana dashboard visually displays the results of the tests. The steps requ 1. Specify the dispatcher to use influxDB to store results. 2. "target = .. " - Specify location of influxDB to store results. "db_name = yardstick" - name of database. Do not change - "username = root" - username to use to store result. (Many tests are run as root) + "username = root" - username to use to store result. (Many tests are + run as root) "password = ... " - Please set to root user password - b. Deploy InfludDB & Grafana. See how to Deploy InfluxDB & Grafana. See `grafana deployment`_. + b. Deploy InfludDB & Grafana. See how to Deploy InfluxDB & Grafana. See + `grafana deployment`_. c. Generate the test data. Run the tests as follows .:: yardstick --debug task start tc_prox_<context>_<test>-ports.yaml @@ -910,7 +973,8 @@ How to run NSB Prox Test on an baremetal environment In order to run the NSB PROX test. - 1. Install NSB on Traffic Generator node and Prox in SUT. See `NSB Installation`_ + 1. Install NSB on Traffic Generator node and Prox in SUT. See + `NSB Installation`_ 2. To enter container:: @@ -922,8 +986,8 @@ In order to run the NSB PROX test. cd /home/opnfv/repos/yardstick/samples/vnf_samples/nsut/prox - b. Install prox-baremetal-2.yam and prox-baremetal-4.yaml for that topology - into this directory as per baremetal-config-label_ + b. Install prox-baremetal-2.yam and prox-baremetal-4.yaml for that + topology into this directory as per baremetal-config-label_ c. Install and configure ``yardstick.conf`` :: @@ -971,7 +1035,8 @@ Here is a list of frequently asked questions. *NSB Prox does not work on Baremetal, How do I resolve this?* ------------------------------------------------------------- -If PROX NSB does not work on baremetal, problem is either in network configuration or test file. +If PROX NSB does not work on baremetal, problem is either in network +configuration or test file. *Solution* @@ -1011,8 +1076,8 @@ If PROX NSB does not work on baremetal, problem is either in network configurati See ``Link detected`` if ``yes`` .... Cable is good. If ``no`` you have an issue with your cable/port. -2. If existing baremetal works then issue is with your test. Check the traffic generator gen_<test>-<ports>.cfg to ensure - it is producing a valid packet. +2. If existing baremetal works then issue is with your test. Check the traffic + generator gen_<test>-<ports>.cfg to ensure it is producing a valid packet. *How do I debug NSB Prox on Baremetal?* --------------------------------------- @@ -1033,7 +1098,8 @@ If PROX NSB does not work on baremetal, problem is either in network configurati cd /opt/nsb_bin/prox -f /tmp/handle_<test>-<ports>.cfg -4. Now let's examine the Generator Output. In this case the output of gen_l2fwd-4.cfg. +4. Now let's examine the Generator Output. In this case the output of + ``gen_l2fwd-4.cfg``. .. image:: images/PROX_Gen_GUI.png :width: 1000px @@ -1048,10 +1114,12 @@ If PROX NSB does not work on baremetal, problem is either in network configurati It appears what is transmitted is received. .. Caution:: - The number of packets MAY not exactly match because the ports are read in sequence. + The number of packets MAY not exactly match because the ports are read in + sequence. .. Caution:: - What is transmitted on PORT X may not always be received on same port. Please check the Test scenario. + What is transmitted on PORT X may not always be received on same port. + Please check the Test scenario. 5. Now lets examine the SUT Output @@ -1083,17 +1151,18 @@ If PROX NSB does not work on baremetal, problem is either in network configurati *NSB Prox works on Baremetal but not in Openstack. How do I resolve this?* -------------------------------------------------------------------------- -NSB Prox on Baremetal is a lot more forgiving than NSB Prox on Openstack. A badly -formed packed may still work with PROX on Baremetal. However on +NSB Prox on Baremetal is a lot more forgiving than NSB Prox on Openstack. A +badly formed packed may still work with PROX on Baremetal. However on Openstack the packet must be correct and all fields of the header correct. -Eg A packet with an invalid Protocol ID would still work in Baremetal -but this packet would be rejected by openstack. +E.g. A packet with an invalid Protocol ID would still work in Baremetal but +this packet would be rejected by openstack. *Solution* 1. Check the validity of the packet. 2. Use a known good packet in your test - 3. If using ``Random`` fields in the traffic generator, disable them and retry. + 3. If using ``Random`` fields in the traffic generator, disable them and + retry. *How do I debug NSB Prox on Openstack?* @@ -1111,7 +1180,8 @@ but this packet would be rejected by openstack. 3. Install openstack credentials. - Depending on your openstack deployment, the location of these credentials may vary. + Depending on your openstack deployment, the location of these credentials + may vary. On this platform I do this via:: scp root@10.237.222.55:/etc/kolla/admin-openrc.sh . @@ -1127,8 +1197,8 @@ but this packet would be rejected by openstack. b. Get the Floating IP of the Traffic Generator & SUT - This generates a lot of information. Please not the floating IP of the VNF and - the Traffic Generator. + This generates a lot of information. Please note the floating IP of the + VNF and the Traffic Generator. .. image:: images/PROX_Openstack_stack_show_a.png :width: 1000px @@ -1215,7 +1285,8 @@ If it fails due to :: Missing value auth-url required for auth plugin password -Check your shell environment for Openstack variables. One of them should contain the authentication URL :: +Check your shell environment for Openstack variables. One of them should +contain the authentication URL :: OS_AUTH_URL=``https://192.168.72.41:5000/v3`` @@ -1239,16 +1310,16 @@ Result :: and visible. -If the Openstack Cli appears to hang, then verify the proxys and no_proxy are set correctly. -They should be similar to :: +If the Openstack ClI appears to hang, then verify the proxys and ``no_proxy`` +are set correctly. They should be similar to :: - FTP_PROXY="http://proxy.ir.intel.com:911/" - HTTPS_PROXY="http://proxy.ir.intel.com:911/" - HTTP_PROXY="http://proxy.ir.intel.com:911/" + FTP_PROXY="http://<your_proxy>:<port>/" + HTTPS_PROXY="http://<your_proxy>:<port>/" + HTTP_PROXY="http://<your_proxy>:<port>/" NO_PROXY="localhost,127.0.0.1,10.237.222.55,10.237.223.80,10.237.222.134,.ir.intel.com" - ftp_proxy="http://proxy.ir.intel.com:911/" - http_proxy="http://proxy.ir.intel.com:911/" - https_proxy="http://proxy.ir.intel.com:911/" + ftp_proxy="http://<your_proxy>:<port>/" + http_proxy="http://<your_proxy>:<port>/" + https_proxy="http://<your_proxy>:<port>/" no_proxy="localhost,127.0.0.1,10.237.222.55,10.237.223.80,10.237.222.134,.ir.intel.com" Where @@ -1256,8 +1327,6 @@ Where 1) 10.237.222.55 = IP Address of deployment node 2) 10.237.223.80 = IP Address of Controller node 3) 10.237.222.134 = IP Address of Compute Node - 4) ir.intel.com = local no proxy - *How to Understand the Grafana output?* --------------------------------------- @@ -1280,48 +1349,48 @@ Where A. Test Parameters - Test interval, Duartion, Tolerated Loss and Test Precision -B. Overall No of packets send and received during test +B. No. of packets send and received during test C. Generator Stats - packets sent, received and attempted by Generator -D. Packets Size - -E. No of packets received by SUT - -F. No of packets forwarded by SUT - -G. This is the number of packets sent by the generator per port, for each interval. +D. Packet size -H. This is the number of packets received by the generator per port, for each interval. +E. No. of packets received by SUT -I. This is the number of packets send and received by the generator and lost by the SUT - that meet the success criteria +F. No. of packets forwarded by SUT -J. This is the changes the Percentage of Line Rate used over a test, The MAX and the - MIN should converge to within the interval specified as the ``test-precision``. +G. No. of packets sent by the generator per port, for each interval. -K. This is the packets Size supported during test. If "N/A" appears in any field the result has not been decided. +H. No. of packets received by the generator per port, for each interval. -L. This is the calculated throughput in MPPS(Million Packets Per second) for this line rate. +I. No. of packets sent and received by the generator and lost by the SUT that + meet the success criteria -M. This is the actual No, of packets sent by the generator in MPPS +J. The change in the Percentage of Line Rate used over a test, The MAX and the + MIN should converge to within the interval specified as the + ``test-precision``. -N. This is the actual No. of packets received by the generator in MPPS +K. Packet size supported during test. If *N/A* appears in any field the + result has not been decided. -O. This is the total No. of packets sent by SUT. +L. Calculated throughput in MPPS (Million Packets Per second) for this line + rate. -P. This is the total No. of packets received by the SUT +M. No. of packets sent by the generator in MPPS -Q. This is the total No. of packets dropped. (These packets were sent by the generator but not - received back by the generator, these may be dropped by the SUT or the Generator) +N. No. of packets received by the generator in MPPS -R. This is the tolerated no of packets that can be dropped. +O. No. of packets sent by SUT. -S. This is the test Throughput in Gbps +P. No. of packets received by the SUT -T. This is the Latencey per Port +Q. Total no. of dropped packets -- Packets sent but not received back by the + generator, these may be dropped by the SUT or the generator. -U. This is the CPU Utilization +R. The tolerated no. of dropped packets. +S. Test throughput in Gbps +T. Latencey per Port +U. CPU Utilization diff --git a/docs/testing/user/userguide/01-introduction.rst b/docs/testing/user/userguide/01-introduction.rst index 74e752d63..5fc2e8d0f 100755 --- a/docs/testing/user/userguide/01-introduction.rst +++ b/docs/testing/user/userguide/01-introduction.rst @@ -83,4 +83,4 @@ Contact Yardstick Feedback? `Contact us`_ -.. _Contact us: mailto:opnfv-users@lists.opnfv.org&subject="[yardstick]" +.. _Contact us: mailto:opnfv-users@lists.opnfv.org&subject="#yardstick" diff --git a/docs/testing/user/userguide/03-architecture.rst b/docs/testing/user/userguide/03-architecture.rst index 886631510..62250d6a3 100755 --- a/docs/testing/user/userguide/03-architecture.rst +++ b/docs/testing/user/userguide/03-architecture.rst @@ -243,26 +243,27 @@ Yardstick Directory structure with support for different installers. *docs/* - All documentation is stored here, such as configuration guides, - user guides and Yardstick descriptions. + user guides and Yardstick test case descriptions. *etc/* - Used for test cases requiring specific POD configurations. *samples/* - test case samples are stored here, most of all scenario and - feature's samples are shown in this directory. + feature samples are shown in this directory. -*tests/* - Here both Yardstick internal tests (*functional/* and *unit/*) as - well as the test cases run to verify the NFVI (*opnfv/*) are stored. - Also configurations of what to run daily and weekly at the different - PODs is located here. +*tests/* - The test cases run to verify the NFVI (*opnfv/*) are stored here. + The configurations of what to run daily and weekly at the different + PODs are also located here. -*tools/* - Currently contains tools to build image for VMs which are deployed - by Heat. Currently contains how to build the yardstick-trusty-server - image with the different tools that are needed from within the - image. +*tools/* - Contains tools to build image for VMs which are deployed by Heat. + Currently contains how to build the yardstick-image with the + different tools that are needed from within the image. *plugin/* - Plug-in configuration files are stored here. -*yardstick/* - Contains the internals of Yardstick: Runners, Scenario, Contexts, - CLI parsing, keys, plotting tools, dispatcher, plugin +*yardstick/* - Contains the internals of Yardstick: :term:`Runners <runner>`, + :term:`Scenarios <scenario>`, :term:`Contexts <context>`, CLI + parsing, keys, plotting tools, dispatcher, plugin install/remove scripts and so on. +*yardstick/tests* - The Yardstick internal tests (*functional/* and *unit/*) + are stored here. diff --git a/docs/testing/user/userguide/04-installation.rst b/docs/testing/user/userguide/04-installation.rst index 6b3259299..2f8175c25 100644 --- a/docs/testing/user/userguide/04-installation.rst +++ b/docs/testing/user/userguide/04-installation.rst @@ -575,17 +575,17 @@ Grafana to display data in the following sections. Automatic deployment of InfluxDB and Grafana containers (**recommended**) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Firstly, enter the Yardstick container:: +1. Enter the Yardstick container:: - sudo -EH docker exec -it yardstick /bin/bash + sudo -EH docker exec -it yardstick /bin/bash -Secondly, create InfluxDB container and configure with the following command:: +2. Create InfluxDB container and configure with the following command:: - yardstick env influxdb + yardstick env influxdb -Thirdly, create and configure Grafana container:: +3. Create and configure Grafana container:: - yardstick env grafana + yardstick env grafana Then you can run a test case and visit http://host_ip:1948 (``admin``/``admin``) to see the results. @@ -613,21 +613,21 @@ Run influxDB:: sudo -EH docker run -d --name influxdb \ -p 8083:8083 -p 8086:8086 --expose 8090 --expose 8099 \ tutum/influxdb - docker exec -it influxdb bash + docker exec -it influxdb influx Configure influxDB:: - influx - >CREATE USER root WITH PASSWORD 'root' WITH ALL PRIVILEGES - >CREATE DATABASE yardstick; - >use yardstick; - >show MEASUREMENTS; + > CREATE USER root WITH PASSWORD 'root' WITH ALL PRIVILEGES + > CREATE DATABASE yardstick; + > use yardstick; + > show MEASUREMENTS; + > quit Run Grafana:: sudo -EH docker run -d --name grafana -p 1948:3000 grafana/grafana -Log on http://{YOUR_IP_HERE}:1948 using ``admin``/``admin`` and configure +Log on to ``http://{YOUR_IP_HERE}:1948`` using ``admin``/``admin`` and configure database resource to be ``{YOUR_IP_HERE}:8086``. .. image:: images/Grafana_config.png @@ -640,7 +640,7 @@ Configure ``yardstick.conf``:: sudo cp etc/yardstick/yardstick.conf.sample /etc/yardstick/yardstick.conf sudo vi /etc/yardstick/yardstick.conf -Modify ``yardstick.conf``:: +Modify ``yardstick.conf`` to add the ``influxdb`` dispatcher:: [DEFAULT] debug = True @@ -653,7 +653,7 @@ Modify ``yardstick.conf``:: username = root password = root -Now you can run Yardstick test cases and store the results in influxDB. +Now Yardstick will store results in InfluxDB when you run a testcase. Deploy InfluxDB and Grafana directly in Ubuntu (**Todo**) diff --git a/docs/testing/user/userguide/13-nsb-installation.rst b/docs/testing/user/userguide/13-nsb-installation.rst index 363ad4852..973d56628 100644 --- a/docs/testing/user/userguide/13-nsb-installation.rst +++ b/docs/testing/user/userguide/13-nsb-installation.rst @@ -1,7 +1,7 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International .. License. .. http://creativecommons.org/licenses/by/4.0 -.. (c) OPNFV, 2016-2017 Intel Corporation. +.. (c) OPNFV, 2016-2018 Intel Corporation. .. Convention for heading levels in Yardstick documentation: @@ -936,7 +936,7 @@ Setup system proxy (if needed). Add the following configuration into the ``/etc/environment`` file: .. note:: The proxy server name/port and IPs should be changed according to - actuall/current proxy configuration in the lab. + actual/current proxy configuration in the lab. .. code:: bash @@ -1192,3 +1192,52 @@ installed as part of the requirements of the project. 3. Execute testcase in samplevnf folder e.g. ``<repo>/samples/vnf_samples/nsut/vfw/tc_baremetal_rfc2544_ipv4_1rule_1flow_64B_ixia.yaml`` + +Spirent Landslide +----------------- + +In order to use Spirent Landslide for vEPC testcases, some dependencies have +to be preinstalled and properly configured. + +- Java + + 32-bit Java installation is required for the Spirent Landslide TCL API. + + | ``$ sudo apt-get install openjdk-8-jdk:i386`` + + .. important:: + Make sure ``LD_LIBRARY_PATH`` is pointing to 32-bit JRE. For more details + check `Linux Troubleshooting <http://TAS_HOST_IP/tclapiinstall.html#trouble>` + section of installation instructions. + +- LsApi (Tcl API module) + + Follow Landslide documentation for detailed instructions on Linux + installation of Tcl API and its dependencies + ``http://TAS_HOST_IP/tclapiinstall.html``. + For working with LsApi Python wrapper only steps 1-5 are required. + + .. note:: After installation make sure your API home path is included in + ``PYTHONPATH`` environment variable. + + .. important:: + The current version of LsApi module has an issue with reading LD_LIBRARY_PATH. + For LsApi module to initialize correctly following lines (184-186) in + lsapi.py + + .. code-block:: python + + ldpath = os.environ.get('LD_LIBRARY_PATH', '') + if ldpath == '': + environ['LD_LIBRARY_PATH'] = environ['LD_LIBRARY_PATH'] + ':' + ldpath + + should be changed to: + + .. code-block:: python + + ldpath = os.environ.get('LD_LIBRARY_PATH', '') + if not ldpath == '': + environ['LD_LIBRARY_PATH'] = environ['LD_LIBRARY_PATH'] + ':' + ldpath + +.. note:: The Spirent landslide TCL software package needs to be updated in case + the user upgrades to a new version of Spirent landslide software. diff --git a/docs/testing/user/userguide/14-nsb-operation.rst b/docs/testing/user/userguide/14-nsb-operation.rst index b4adf7855..c96155804 100644 --- a/docs/testing/user/userguide/14-nsb-operation.rst +++ b/docs/testing/user/userguide/14-nsb-operation.rst @@ -1,7 +1,7 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International .. License. .. http://creativecommons.org/licenses/by/4.0 -.. (c) OPNFV, 2016-2017 Intel Corporation. +.. (c) OPNFV, 2016-2018 Intel Corporation. Yardstick - NSB Testing - Operation =================================== @@ -459,3 +459,108 @@ Sample test case file .. literalinclude:: /../samples/vnf_samples/nsut/acl/tc_ovs_rfc2544_ipv4_1rule_1flow_64B_trex.yaml :language: yaml + +Preparing test run of vEPC test case +------------------------------------ + +Provided vEPC test cases are examples of emulation of vEPC infrastructure +components, such as UE, eNodeB, MME, SGW, PGW. + +Location of vEPC test cases: ``samples/vnf_samples/nsut/vepc/``. + +Before running a specific vEPC test case using NSB, some preconfiguration +needs to be done. + +Update Spirent Landslide TG configuration in pod file +===================================================== + +Examples of ``pod.yaml`` files could be found in +:file:`etc/yardstick/nodes/standalone`. +The name of related pod file could be checked in the context section of NSB +test case. + +The ``pod.yaml`` related to vEPC test case uses some sub-structures that hold the +details of accessing the Spirent Landslide traffic generator. +These subsections and the changes to be done in provided example pod file are +described below. + +1. ``tas_manager``: data under this key holds the information required to +access Landslide TAS (Test Administration Server) and perform needed +configurations on it. + + * ``ip``: IP address of TAS Manager node; should be updated according to test + setup used + * ``super_user``: superuser name; could be retrieved from Landslide documentation + * ``super_user_password``: superuser password; could be retrieved from + Landslide documentation + * ``cfguser_password``: password of predefined user named 'cfguser'; default + password could be retrieved from Landslide documentation + * ``test_user``: username to be used during test run as a Landslide library + name; to be defined by test run operator + * ``test_user_password``: password of test user; to be defined by test run + operator + * ``proto``: *http* or *https*; to be defined by test run operator + * ``license``: Landslide license number installed on TAS + +2. The ``config`` section holds information about test servers (TSs) and +systems under test (SUTs). Data is represented as a list of entries. +Each such entry contains: + + * ``test_server``: this subsection represents data related to test server + configuration, such as: + + * ``name``: test server name; unique custom name to be defined by test + operator + * ``role``: this value is used as a key to bind specific Test Server and + TestCase; should be set to one of test types supported by TAS license + * ``ip``: Test Server IP address + * ``thread_model``: parameter related to Test Server performance mode. + The value should be one of the following: "Legacy" | "Max" | "Fireball". + Refer to Landslide documentation for details. + * ``phySubnets``: a structure used to specify IP ranges reservations on + specific network interfaces of related Test Server. Structure fields are: + + * ``base``: start of IP address range + * ``mask``: IP range mask in CIDR format + * ``name``: network interface name, e.g. *eth1* + * ``numIps``: size of IP address range + + * ``preResolvedArpAddress``: a structure used to specify the range of IP + addresses for which the ARP responses will be emulated + + * ``StartingAddress``: IP address specifying the start of IP address range + * ``NumNodes``: size of the IP address range + + * ``suts``: a structure that contains definitions of each specific SUT + (represents a vEPC component). SUT structure contains following key/value + pairs: + + * ``name``: unique custom string specifying SUT name + * ``role``: string value corresponding with an SUT role specified in the + session profile (test session template) file + * ``managementIp``: SUT management IP adress + * ``phy``: network interface name, e.g. *eth1* + * ``ip``: vEPC component IP address used in test case topology + * ``nextHop``: next hop IP address, to allow for vEPC inter-node communication + +Update NSB test case definitions +================================ +NSB test case file designated for vEPC testing contains an example of specific +test scenario configuration. +Test operator may change these definitions as required for the use case that +requires testing. +Specifically, following subsections of the vEPC test case (section **scenarios**) +may be changed. + +1. Subsection ``options``: contains custom parameters used for vEPC testing + + * subsection ``dmf``: may contain one or more parameters specified in + ``traffic_profile`` template file + * subsection ``test_cases``: contains re-definitions of parameters specified + in ``session_profile`` template file + + .. note:: All parameters in ``session_profile``, value of which is a + placeholder, needs to be re-defined to construct a valid test session. + +2. Subsection ``runner``: specifies the test duration and the interval of +TG and VNF side KPIs polling. For more details, refer to :doc:`03-architecture`. diff --git a/docs/testing/user/userguide/15-list-of-tcs.rst b/docs/testing/user/userguide/15-list-of-tcs.rst index 2f0a87144..8990800c1 100644 --- a/docs/testing/user/userguide/15-list-of-tcs.rst +++ b/docs/testing/user/userguide/15-list-of-tcs.rst @@ -29,6 +29,7 @@ Generic NFVI Test Case Descriptions opnfv_yardstick_tc002.rst opnfv_yardstick_tc004.rst opnfv_yardstick_tc005.rst + opnfv_yardstick_tc006.rst opnfv_yardstick_tc008.rst opnfv_yardstick_tc009.rst opnfv_yardstick_tc010.rst @@ -57,6 +58,7 @@ Generic NFVI Test Case Descriptions opnfv_yardstick_tc080.rst opnfv_yardstick_tc081.rst opnfv_yardstick_tc083.rst + opnfv_yardstick_tc084.rst OPNFV Feature Test Cases ======================== @@ -83,6 +85,10 @@ H A opnfv_yardstick_tc057.rst opnfv_yardstick_tc058.rst opnfv_yardstick_tc087.rst + opnfv_yardstick_tc088.rst + opnfv_yardstick_tc089.rst + opnfv_yardstick_tc090.rst + opnfv_yardstick_tc091.rst opnfv_yardstick_tc092.rst opnfv_yardstick_tc093.rst diff --git a/docs/testing/user/userguide/nsb/nsb-list-of-tcs.rst b/docs/testing/user/userguide/nsb/nsb-list-of-tcs.rst index f9ca900fd..723cd6f99 100644 --- a/docs/testing/user/userguide/nsb/nsb-list-of-tcs.rst +++ b/docs/testing/user/userguide/nsb/nsb-list-of-tcs.rst @@ -27,7 +27,7 @@ NSB PROX Test Case Descriptions tc_prox_context_buffering_port tc_prox_context_load_balancer_port tc_prox_context_vpe_port - tc_prox_context_lw_after_port + tc_prox_context_lw_aftr_port tc_epc_default_bearer_landslide tc_epc_dedicated_bearer_landslide tc_epc_saegw_tput_relocation_landslide |