diff options
Diffstat (limited to 'docs/testing/user')
20 files changed, 1054 insertions, 107 deletions
diff --git a/docs/testing/user/userguide/08-api.rst b/docs/testing/user/userguide/08-api.rst index 92fa408c8..2206c2ac8 100644 --- a/docs/testing/user/userguide/08-api.rst +++ b/docs/testing/user/userguide/08-api.rst @@ -35,7 +35,7 @@ Prepare Yardstick test environment Example:: { - 'action': 'prepareYardstickEnv' + 'action': 'prepare_env' } This is an asynchronous API. You need to call /yardstick/asynctask API to get the task result. @@ -45,7 +45,7 @@ Start and config an InfluxDB docker container Example:: { - 'action': 'createInfluxDBContainer' + 'action': 'create_influxdb' } This is an asynchronous API. You need to call /yardstick/asynctask API to get the task result. @@ -55,7 +55,7 @@ Start and config a Grafana docker container Example:: { - 'action': 'createGrafanaContainer' + 'action': 'create_grafana' } This is an asynchronous API. You need to call /yardstick/asynctask API to get the task result. @@ -73,10 +73,15 @@ Method: GET Get the status of asynchronous tasks Example:: - http://localhost:8888/yardstick/asynctask?task_id=3f3f5e03-972a-4847-a5f8-154f1b31db8c + http://<SERVER IP>:<PORT>/yardstick/asynctask?task_id=3f3f5e03-972a-4847-a5f8-154f1b31db8c The returned status will be 0(running), 1(finished) and 2(failed). +NOTE:: + + <SERVER IP>: The ip of the host where you start your yardstick container + <PORT>: The outside port of port mapping which set when you start start yardstick container + /yardstick/testcases ^^^^^^^^^^^^^^^^^^^^ @@ -90,7 +95,7 @@ Method: GET Get a list of released test cases Example:: - http://localhost:8888/yardstick/testcases + http://<SERVER IP>:<PORT>/yardstick/testcases /yardstick/testcases/release/action @@ -106,10 +111,10 @@ Run a released test case Example:: { - 'action': 'runTestCase', + 'action': 'run_test_case', 'args': { 'opts': {}, - 'testcase': 'tc002' + 'testcase': 'opnfv_yardstick_tc002' } } @@ -129,7 +134,7 @@ Run a sample test case Example:: { - 'action': 'runTestCase', + 'action': 'run_test_case', 'args': { 'opts': {}, 'testcase': 'ping' @@ -151,7 +156,7 @@ Method: GET Get the documentation of a certain test case Example:: - http://localhost:8888/yardstick/taskcases/opnfv_yardstick_tc002/docs + http://<SERVER IP>:<PORT>/yardstick/taskcases/opnfv_yardstick_tc002/docs /yardstick/testsuites/action @@ -167,10 +172,10 @@ Run a test suite Example:: { - 'action': 'runTestSuite', + 'action': 'run_test_suite', 'args': { 'opts': {}, - 'testcase': 'smoke' + 'testsuite': 'opnfv_smoke' } } @@ -178,6 +183,7 @@ This is an asynchronous API. You need to call /yardstick/results to get the resu /yardstick/tasks/<task_id>/log +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: This API is used to get the real time log of test case execution. @@ -188,7 +194,7 @@ Method: GET Get real time of test case execution Example:: - http://localhost:8888/yardstick/tasks/14795be8-f144-4f54-81ce-43f4e3eab33f/log?index=0 + http://<SERVER IP>:<PORT>/yardstick/tasks/14795be8-f144-4f54-81ce-43f4e3eab33f/log?index=0 /yardstick/results @@ -203,17 +209,18 @@ Method: GET Get test results of one task Example:: - http://localhost:8888/yardstick/results?task_id=3f3f5e03-972a-4847-a5f8-154f1b31db8c + http://<SERVER IP>:<PORT>/yardstick/results?task_id=3f3f5e03-972a-4847-a5f8-154f1b31db8c This API will return a list of test case result -/api/v2/yardstick/openrcs/action +/api/v2/yardstick/openrcs +^^^^^^^^^^^^^^^^^^^^^^^^^ Description: This API provides functionality of handling OpenStack credential file (openrc). For Euphrates, it supports: 1. Upload an openrc file for an OpenStack environment; -2. Update an openrc file; +2. Update an openrc; 3. Get openrc file information; 4. Delete an openrc file. @@ -260,12 +267,21 @@ Example:: } +/api/v2/yardstick/openrcs/<openrc_id> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Description: This API provides functionality of handling OpenStack credential file (openrc). For Euphrates, it supports: + +1. Get openrc file information; +2. Delete an openrc file. + + METHOD: GET Get openrc file information Example:: - http://localhost:8888/api/v2/yardstick/openrcs/5g6g3e02-155a-4847-a5f8-154f1b31db8c + http://<SERVER IP>:<PORT>/api/v2/yardstick/openrcs/5g6g3e02-155a-4847-a5f8-154f1b31db8c METHOD: DELETE @@ -274,16 +290,15 @@ METHOD: DELETE Delete openrc file Example:: - http://localhost:8888/api/v2/yardstick/openrcs/5g6g3e02-155a-4847-a5f8-154f1b31db8c + http://<SERVER IP>:<PORT>/api/v2/yardstick/openrcs/5g6g3e02-155a-4847-a5f8-154f1b31db8c -/api/v2/yardstick/pods/action +/api/v2/yardstick/pods +^^^^^^^^^^^^^^^^^^^^^^ Description: This API provides functionality of handling Yardstick pod file (pod.yaml). For Euphrates, it supports: 1. Upload a pod file; -2. Get pod file information; -3. Delete an openrc file. Which API to call will depend on the parameters. @@ -303,12 +318,20 @@ Example:: } +/api/v2/yardstick/pods/<pod_id> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Description: This API provides functionality of handling Yardstick pod file (pod.yaml). For Euphrates, it supports: + +1. Get pod file information; +2. Delete an openrc file. + METHOD: GET Get pod file information Example:: - http://localhost:8888/api/v2/yardstick/pods/5g6g3e02-155a-4847-a5f8-154f1b31db8c + http://<SERVER IP>:<PORT>/api/v2/yardstick/pods/5g6g3e02-155a-4847-a5f8-154f1b31db8c METHOD: DELETE @@ -316,16 +339,15 @@ METHOD: DELETE Delete openrc file Example:: - http://localhost:8888/api/v2/yardstick/pods/5g6g3e02-155a-4847-a5f8-154f1b31db8c + http://<SERVER IP>:<PORT>/api/v2/yardstick/pods/5g6g3e02-155a-4847-a5f8-154f1b31db8c -/api/v2/yardstick/images/action +/api/v2/yardstick/images +^^^^^^^^^^^^^^^^^^^^^^^^ Description: This API is used to do some work related to Yardstick VM images. For Euphrates, it supports: 1. Load Yardstick VM images; -2. Get image's information; -3. Delete images. Which API to call will depend on the parameters. @@ -337,16 +359,27 @@ Load VM images Example:: { - 'action': 'load_images' + 'action': 'load_image', + 'args': { + 'name': 'yardstick-image' + } } +/api/v2/yardstick/images/<image_id> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Description: This API is used to do some work related to Yardstick VM images. For Euphrates, it supports: + +1. Get image's information; +2. Delete images + METHOD: GET Get image information Example:: - http://localhost:8888/api/v2/yardstick/images/5g6g3e02-155a-4847-a5f8-154f1b31db8c + http://<SERVER IP>:<PORT>/api/v2/yardstick/images/5g6g3e02-155a-4847-a5f8-154f1b31db8c METHOD: DELETE @@ -354,19 +387,15 @@ METHOD: DELETE Delete images Example:: - http://localhost:8888/api/v2/yardstick/images/5g6g3e02-155a-4847-a5f8-154f1b31db8c + http://<SERVER IP>:<PORT>/api/v2/yardstick/images/5g6g3e02-155a-4847-a5f8-154f1b31db8c -/api/v2/yardstick/tasks/action +/api/v2/yardstick/tasks +^^^^^^^^^^^^^^^^^^^^^^^ Description: This API is used to do some work related to yardstick tasks. For Euphrates, it supports: 1. Create a Yardstick task; -2. run a Yardstick task; -3. Add a test case to a task; -4. Add a test suite to a task; -5. Get a tasks' information; -6. Delete a task. Which API to call will depend on the parameters. @@ -386,20 +415,35 @@ Example:: } +/api/v2/yardstick/tasks/<task_id> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Description: This API is used to do some work related to yardstick tasks. For Euphrates, it supports: + +1. Add a environment to a task +2. Add a test case to a task; +3. Add a test suite to a task; +4. run a Yardstick task; +5. Get a tasks' information; +6. Delete a task. + + METHOD: PUT +Add a environment to a task -Run a task Example:: { - 'action': 'run' + 'action': 'add_environment', + 'args': { + 'environment_id': 'e3cadbbb-0419-4fed-96f1-a232daa0422a' + } } METHOD: PUT - Add a test case to a task Example:: @@ -412,8 +456,8 @@ Example:: } -METHOD: PUT +METHOD: PUT Add a test suite to a task Example:: @@ -427,29 +471,41 @@ Example:: } +METHOD: PUT + +Run a task + +Example:: + + { + 'action': 'run' + } + + + METHOD: GET Get a task's information Example:: - http://localhost:8888/api/v2/yardstick/tasks/5g6g3e02-155a-4847-a5f8-154f1b31db8c + http://<SERVER IP>:<PORT>/api/v2/yardstick/tasks/5g6g3e02-155a-4847-a5f8-154f1b31db8c METHOD: DELETE Delete a task + Example:: - http://localhost:8888/api/v2/yardstick/tasks/5g6g3e02-155a-4847-a5f8-154f1b31db8c + http://<SERVER IP>:<PORT>/api/v2/yardstick/tasks/5g6g3e02-155a-4847-a5f8-154f1b31db8c -/api/v2/yardstick/testcases/action +/api/v2/yardstick/testcases +^^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: This API is used to do some work related to yardstick testcases. For Euphrates, it supports: 1. Upload a test case; 2. Get all released test cases' information; -3. Get a certain released test case's information; -4. Delete a test case. Which API to call will depend on the parameters. @@ -474,16 +530,24 @@ METHOD: GET Get all released test cases' information Example:: - http://localhost:8888/api/v2/yardstick/testcases + http://<SERVER IP>:<PORT>/api/v2/yardstick/testcases + + +/api/v2/yardstick/testcases/<case_name> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Description: This API is used to do some work related to yardstick testcases. For Euphrates, it supports: +1. Get certain released test case's information; +2. Delete a test case. METHOD: GET -Get a certain released test case's information +Get certain released test case's information Example:: - http://localhost:8888/api/v2/yardstick/testcases/opnfv_yardstick_tc002 + http://<SERVER IP>:<PORT>/api/v2/yardstick/testcases/opnfv_yardstick_tc002 METHOD: DELETE @@ -491,17 +555,16 @@ METHOD: DELETE Delete a certain test case Example:: - http://localhost:8888/api/v2/yardstick/testcases/opnfv_yardstick_tc002 + http://<SERVER IP>:<PORT>/api/v2/yardstick/testcases/opnfv_yardstick_tc002 -/api/v2/yardstick/testsuites/action +/api/v2/yardstick/testsuites +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: This API is used to do some work related to yardstick test suites. For Euphrates, it supports: 1. Create a test suite; -2. Get a certain test suite's information; -3. Get all test suites; -4. Delete a test case. +2. Get all test suites; Which API to call will depend on the parameters. @@ -513,7 +576,7 @@ Create a test suite Example:: { - 'action': 'create_sutie', + 'action': 'create_suite', 'args': { 'name': <suite_name>, 'testcases': [ @@ -526,19 +589,27 @@ Example:: METHOD: GET -Get a certain test suite's information +Get all test suite Example:: - http://localhost:8888/api/v2/yardstick/testsuites/<suite_name> + http://<SERVER IP>:<PORT>/api/v2/yardstick/testsuites + + +/api/v2/yardstick/testsuites +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Description: This API is used to do some work related to yardstick test suites. For Euphrates, it supports: +1. Get certain test suite's information; +2. Delete a test case. METHOD: GET -Get all test suite +Get certain test suite's information Example:: - http://localhost:8888/api/v2/yardstick/testsuites + http://<SERVER IP>:<PORT>/api/v2/yardstick/testsuites/<suite_name> METHOD: DELETE @@ -547,17 +618,16 @@ METHOD: DELETE Delete a certain test suite Example:: - http://localhost:8888/api/v2/yardstick/testsuites/<suite_name> + http://<SERVER IP>:<PORT>/api/v2/yardstick/testsuites/<suite_name> -/api/v2/yardstick/projects/action +/api/v2/yardstick/projects +^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: This API is used to do some work related to yardstick test projects. For Euphrates, it supports: 1. Create a Yardstick project; -2. Get a certain project's information; -3. Get all projects; -4. Delete a project. +2. Get all projects; Which API to call will depend on the parameters. @@ -579,19 +649,27 @@ Example:: METHOD: GET -Get a certain project's information +Get all projects' information Example:: - http://localhost:8888/api/v2/yardstick/projects/<project_id> + http://<SERVER IP>:<PORT>/api/v2/yardstick/projects + +/api/v2/yardstick/projects +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Description: This API is used to do some work related to yardstick test projects. For Euphrates, it supports: + +1. Get certain project's information; +2. Delete a project. METHOD: GET -Get all projects' information +Get certain project's information Example:: - http://localhost:8888/api/v2/yardstick/projects + http://<SERVER IP>:<PORT>/api/v2/yardstick/projects/<project_id> METHOD: DELETE @@ -600,17 +678,16 @@ METHOD: DELETE Delete a certain project Example:: - http://localhost:8888/api/v2/yardstick/projects/<project_id> + http://<SERVER IP>:<PORT>/api/v2/yardstick/projects/<project_id> -/api/v2/yardstick/containers/action +/api/v2/yardstick/containers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Description: This API is used to do some work related to Docker containers. For Euphrates, it supports: 1. Create a Grafana Docker container; 2. Create an InfluxDB Docker container; -3. Get a certain container's information; -4. Delete a container. Which API to call will depend on the parameters. @@ -643,13 +720,21 @@ Example:: } +/api/v2/yardstick/containers/<container_id> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Description: This API is used to do some work related to Docker containers. For Euphrates, it supports: + +1. Get certain container's information; +2. Delete a container. + METHOD: GET -Get a certain container's information +Get certain container's information Example:: - http://localhost:8888/api/v2/yardstick/containers/<container_id> + http://<SERVER IP>:<PORT>/api/v2/yardstick/containers/<container_id> METHOD: DELETE @@ -658,4 +743,4 @@ METHOD: DELETE Delete a certain container Example:: - http://localhost:8888/api/v2/yardstick/containers/<container_id> + http://<SERVER IP>:<PORT>/api/v2/yardstick/containers/<container_id> diff --git a/docs/testing/user/userguide/11-nsb-overview.rst b/docs/testing/user/userguide/11-nsb-overview.rst index 8ce90f65d..332dba47d 100644 --- a/docs/testing/user/userguide/11-nsb-overview.rst +++ b/docs/testing/user/userguide/11-nsb-overview.rst @@ -197,7 +197,9 @@ VNFs supported for chracterization: 1. CGNAPT - Carrier Grade Network Address and port Translation 2. vFW - Virtual Firewall 3. vACL - Access Control List -5. Prox - Packet pROcessing eXecution engine: - - VNF can act as Drop, Basic Forwarding (no touch), L2 Forwarding (change MAC), GRE encap/decap, Load balance based on packet fields, Symmetric load balancing, +4. Prox - Packet pROcessing eXecution engine: + - VNF can act as Drop, Basic Forwarding (no touch), + L2 Forwarding (change MAC), GRE encap/decap, Load balance based on + packet fields, Symmetric load balancing - QinQ encap/decap IPv4/IPv6, ARP, QoS, Routing, Unmpls, Policing, ACL -6. UDP_Replay +5. UDP_Replay diff --git a/docs/testing/user/userguide/12-nsb_installation.rst b/docs/testing/user/userguide/12-nsb_installation.rst index a584ca231..5631c6578 100644 --- a/docs/testing/user/userguide/12-nsb_installation.rst +++ b/docs/testing/user/userguide/12-nsb_installation.rst @@ -116,11 +116,13 @@ Configure the network proxy, either using the environment variables or setting the global environment file: .. code-block:: ini + cat /etc/environment http_proxy='http://proxy.company.com:port' https_proxy='http://proxy.company.com:port' .. code-block:: console + export http_proxy='http://proxy.company.com:port' export https_proxy='http://proxy.company.com:port' @@ -128,6 +130,7 @@ The last step is to modify the Yardstick installation inventory, used by Ansible: .. code-block:: ini + cat ./ansible/yardstick-install-inventory.ini [jumphost] localhost ansible_connection=local @@ -753,14 +756,292 @@ Update "contexts" section gateway_ip: '152.16.100.20' +Network Service Benchmarking - OpenStack with SR-IOV support +------------------------------------------------------------ + +This section describes how to run a Sample VNF test case, using Heat context, +with SR-IOV. It also covers how to install OpenStack in Ubuntu 16.04, using +DevStack, with SR-IOV support. + + +Single node OpenStack setup with external TG +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: console + + +----------------------------+ + |OpenStack(DevStack) | + | | + | +--------------------+ | + | |sample-VNF VM | | + | | | | + | | DUT | | + | | (VNF) | | + | | | | + | +--------+ +--------+ | + | | VF NIC | | VF NIC | | + | +-----+--+--+----+---+ | + | ^ ^ | + | | | | + +----------+ +---------+----------+-------+ + | | | VF0 VF1 | + | | | ^ ^ | + | | | | SUT | | + | TG | (PF0)<----->(PF0) +---------+ | | + | | | | | + | | (PF1)<----->(PF1) +--------------------+ | + | | | | + +----------+ +----------------------------+ + trafficgen_1 host + + +Host pre-configuration +###################### + +.. warning:: The following configuration requires sudo access to the system. Make + sure that your user have the access. + +Enable the Intel VT-d or AMD-Vi extension in the BIOS. Some system manufacturers +disable this extension by default. + +Activate the Intel VT-d or AMD-Vi extension in the kernel by modifying the GRUB +config file ``/etc/default/grub``. + +For the Intel platform: + +.. code:: bash + + ... + GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on" + ... + +For the AMD platform: + +.. code:: bash + + ... + GRUB_CMDLINE_LINUX_DEFAULT="amd_iommu=on" + ... + +Update the grub configuration file and restart the system: + +.. warning:: The following command will reboot the system. + +.. code:: bash + + sudo update-grub + sudo reboot + +Make sure the extension has been enabled: + +.. code:: bash + + sudo journalctl -b 0 | grep -e IOMMU -e DMAR + + Feb 06 14:50:14 hostname kernel: ACPI: DMAR 0x000000006C406000 0001E0 (v01 INTEL S2600WF 00000001 INTL 20091013) + Feb 06 14:50:14 hostname kernel: DMAR: IOMMU enabled + Feb 06 14:50:14 hostname kernel: DMAR: Host address width 46 + Feb 06 14:50:14 hostname kernel: DMAR: DRHD base: 0x000000d37fc000 flags: 0x0 + Feb 06 14:50:14 hostname kernel: DMAR: dmar0: reg_base_addr d37fc000 ver 1:0 cap 8d2078c106f0466 ecap f020de + Feb 06 14:50:14 hostname kernel: DMAR: DRHD base: 0x000000e0ffc000 flags: 0x0 + Feb 06 14:50:14 hostname kernel: DMAR: dmar1: reg_base_addr e0ffc000 ver 1:0 cap 8d2078c106f0466 ecap f020de + Feb 06 14:50:14 hostname kernel: DMAR: DRHD base: 0x000000ee7fc000 flags: 0x0 + +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. + +.. code:: bash + + export http_proxy=http://proxy.company.com:port + export https_proxy=http://proxy.company.com:port + export ftp_proxy=http://proxy.company.com:port + export no_proxy=localhost,127.0.0.1,company.com,<IP-OF-HOST1>,<IP-OF-HOST2>,... + export NO_PROXY=localhost,127.0.0.1,company.com,<IP-OF-HOST1>,<IP-OF-HOST2>,... + +Upgrade the system: + +.. code:: bash + + sudo -EH apt-get update + sudo -EH apt-get upgrade + sudo -EH apt-get dist-upgrade + +Install dependencies needed for the DevStack + +.. code:: bash + + sudo -EH apt-get install python + sudo -EH apt-get install python-dev + sudo -EH apt-get install python-pip + +Setup SR-IOV ports on the host: + +.. note:: The ``enp24s0f0``, ``enp24s0f0`` are physical function (PF) interfaces + on a host and ``enp24s0f3`` is a public interface used in OpenStack, so the + interface names should be changed according to the HW environment used for + testing. + +.. code:: bash + + sudo ip link set dev enp24s0f0 up + sudo ip link set dev enp24s0f1 up + sudo ip link set dev enp24s0f3 up + + # Create VFs on PF + echo 2 | sudo tee /sys/class/net/enp24s0f0/device/sriov_numvfs + echo 2 | sudo tee /sys/class/net/enp24s0f1/device/sriov_numvfs + + +DevStack installation +##################### + +Use official `Devstack <https://docs.openstack.org/devstack/pike/>`_ +documentation to install OpenStack on a host. Please note, that stable +``pike`` branch of devstack repo should be used during the installation. +The required `local.conf`` configuration file are described below. + +DevStack configuration file: + +.. note:: Update the devstack configuration file by replacing angluar brackets + with a short description inside. + +.. note:: Use ``lspci | grep Ether`` & ``lspci -n | grep <PCI ADDRESS>`` + commands to get device and vendor id of the virtual function (VF). + +.. literalinclude:: code/single-devstack-local.conf + :language: console + +Start the devstack installation on a host. + + +TG host configuration +##################### + +Yardstick automatically install and configure Trex traffic generator on TG +host based on provided POD file (see below). Anyway, it's recommended to check +the compatibility of the installed NIC on the TG server with software Trex using +the manual at https://trex-tgn.cisco.com/trex/doc/trex_manual.html. + + +Run the Sample VNF test case +############################ + +There is an example of Sample VNF test case ready to be executed in an +OpenStack environment with SR-IOV support: ``samples/vnf_samples/nsut/vfw/ +tc_heat_sriov_external_rfc2544_ipv4_1rule_1flow_64B_trex.yaml``. + +Install yardstick using `Install Yardstick (NSB Testing)`_ steps for OpenStack +context. + +Create pod file for TG in the yardstick repo folder located in the yardstick +container: + +.. note:: The ``ip``, ``user``, ``password`` and ``vpci`` fields show be changed + according to HW environment used for the testing. Use ``lshw -c network -businfo`` + command to get the PF PCI address for ``vpci`` field. + +.. literalinclude:: code/single-yardstick-pod.conf + :language: console + +Run the Sample vFW RFC2544 SR-IOV TC (``samples/vnf_samples/nsut/vfw/ +tc_heat_sriov_external_rfc2544_ipv4_1rule_1flow_64B_trex.yaml``) in the heat +context using steps described in `NS testing - using yardstick CLI`_ section. + + +Multi node OpenStack TG and VNF setup (two nodes) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: console + + +----------------------------+ +----------------------------+ + |OpenStack(DevStack) | |OpenStack(DevStack) | + | | | | + | +--------------------+ | | +--------------------+ | + | |sample-VNF VM | | | |sample-VNF VM | | + | | | | | | | | + | | TG | | | | DUT | | + | | trafficgen_1 | | | | (VNF) | | + | | | | | | | | + | +--------+ +--------+ | | +--------+ +--------+ | + | | VF NIC | | VF NIC | | | | VF NIC | | VF NIC | | + | +----+---+--+----+---+ | | +-----+--+--+----+---+ | + | ^ ^ | | ^ ^ | + | | | | | | | | + +--------+-----------+-------+ +---------+----------+-------+ + | VF0 VF1 | | VF0 VF1 | + | ^ ^ | | ^ ^ | + | | SUT2 | | | | SUT1 | | + | | +-------+ (PF0)<----->(PF0) +---------+ | | + | | | | | | + | +-------------------+ (PF1)<----->(PF1) +--------------------+ | + | | | | + +----------------------------+ +----------------------------+ + host2 (compute) host1 (controller) + + +Controller/Compute pre-configuration +#################################### + +Pre-configuration of the controller and compute hosts are the same as +described in `Host pre-configuration`_ section. Follow the steps in the section. + + +DevStack configuration +###################### + +Use official `Devstack <https://docs.openstack.org/devstack/pike/>`_ +documentation to install OpenStack on a host. Please note, that stable +``pike`` branch of devstack repo should be used during the installation. +The required `local.conf`` configuration file are described below. + +.. note:: Update the devstack configuration files by replacing angluar brackets + with a short description inside. + +.. note:: Use ``lspci | grep Ether`` & ``lspci -n | grep <PCI ADDRESS>`` + commands to get device and vendor id of the virtual function (VF). + +DevStack configuration file for controller host: + +.. literalinclude:: code/multi-devstack-controller-local.conf + :language: console + +DevStack configuration file for compute host: + +.. literalinclude:: code/multi-devstack-compute-local.conf + :language: console + +Start the devstack installation on the controller and compute hosts. + + +Run the sample vFW TC +##################### + +Install yardstick using `Install Yardstick (NSB Testing)`_ steps for OpenStack +context. + +Run sample vFW RFC2544 SR-IOV TC (``samples/vnf_samples/nsut/vfw/ +tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex.yaml``) in the heat +context using steps described in `NS testing - using yardstick CLI`_ section +and the following yardtick command line arguments: + +.. code:: bash + + yardstick -d task start --task-args='{"provider": "sriov"}' \ + samples/vnf_samples/nsut/vfw/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex.yaml + + Enabling other Traffic generator -------------------------------- IxLoad: ^^^^^^^ -1. Software needed: IxLoadAPI ``<IxLoadTclApi verson>Linux64.bin.tgz and <IxOS version>Linux64.bin.tar.gz`` (Download from ixia support site) - Install - ``<IxLoadTclApi verson>Linux64.bin.tgz & <IxOS version>Linux64.bin.tar.gz`` +1. Software needed: IxLoadAPI ``<IxLoadTclApi verson>Linux64.bin.tgz and <IxOS + version>Linux64.bin.tar.gz`` (Download from ixia support site) + Install - ``<IxLoadTclApi verson>Linux64.bin.tgz & <IxOS version>Linux64.bin.tar.gz`` If the installation was not done inside the container, after installing the IXIA client, check /opt/ixia/ixload/<ver>/bin/ixloadpython and make sure you can run this cmd inside the yardstick container. Usually user is required to copy or link /opt/ixia/python/<ver>/bin/ixiapython @@ -818,9 +1099,9 @@ IxLoad: - Connect to the IxLoad machine using RDP - Go to: - ``Start->Programs->Ixia->IxOS->IxOS 8.01-GA-Patch1->Ixia Tcl Server IxOS 8.01-GA-Patch1`` + ``Start->Programs->Ixia->IxOS->IxOS 8.01-GA-Patch1->Ixia Tcl Server IxOS 8.01-GA-Patch1`` or - ``"C:\Program Files (x86)\Ixia\IxOS\8.01-GA-Patch1\ixTclServer.exe"`` + ``"C:\Program Files (x86)\Ixia\IxOS\8.01-GA-Patch1\ixTclServer.exe"`` 4. Create a folder "Results" in c:\ and share the folder on the network. diff --git a/docs/testing/user/userguide/13-nsb_operation.rst b/docs/testing/user/userguide/13-nsb_operation.rst index 8c477fa3f..e791b048d 100644 --- a/docs/testing/user/userguide/13-nsb_operation.rst +++ b/docs/testing/user/userguide/13-nsb_operation.rst @@ -126,7 +126,7 @@ To collectd KPIs from the NFVi compute nodes: Scale-Up ------------------- +-------- VNFs performance data with scale-up @@ -137,21 +137,59 @@ VNFs performance data with scale-up Heat ^^^^ -For VNF scale-up tests we increase the number for VNF worker threads. In the case of VNFs +For VNF scale-up tests we increase the number for VNF worker threads and ports. In the case of VNFs we also need to increase the number of VCPUs and memory allocated to the VNF. An example scale-up Heat testcase is: +.. literalinclude:: /submodules/yardstick/samples/vnf_samples/nsut/vfw/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale-up.yaml + :language: yaml + +This testcase template requires specifying the number of VCPUs, Memory and Ports. +We set the VCPUs and memory using the ``--task-args`` options + .. code-block:: console - <repo>/samples/vnf_samples/nsut/acl/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale_up.yaml + yardstick task start --task-args='{"mem": 10480, "vcpus": 4, "ports": 2}' \ + samples/vnf_samples/nsut/vfw/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale-up.yaml -This testcase template requires specifying the number of VCPUs and Memory. -We set the VCPUs and memory using the --task-args options +In order to support ports scale-up, traffic and topology templates need to be used in testcase. -.. code-block:: console +A example topology template is: + +.. literalinclude:: /submodules/yardstick/samples/vnf_samples/nsut/vfw/vfw-tg-topology-scale-up.yaml + :language: yaml + +This template has ``vports`` as an argument. To pass this argument it needs to +be configured in ``extra_args`` scenario definition. Please note that more +argument can be defined in that section. All of them will be passed to topology +and traffic profile templates + +For example: + +.. code-block:: yaml - yardstick --debug task start --task-args='{"mem": 20480, "vcpus": 10}' samples/vnf_samples/nsut/acl/tc_heat_rfc2544_ipv4_1rule_1flow_64B_trex_scale_up.yaml + schema: yardstick:task:0.1 + scenarios: + - type: NSPerf + traffic_profile: ../../traffic_profiles/ipv4_throughput-scale-up.yaml + extra_args: + vports: {{ vports }} + topology: vfw-tg-topology-scale-up.yaml + +A example traffic profile template is: + +.. literalinclude:: /submodules/yardstick/samples/vnf_samples/traffic_profiles/ipv4_throughput-scale-up.yaml + :language: yaml + +There is an option to provide predefined config for SampleVNFs. Path to config +file may by specified in ``vnf_config`` scenario section. + +.. code-block:: yaml + + vnf__0: + rules: acl_1rule.yaml + vnf_config: {lb_config: 'SW', file: vfw_vnf_pipeline_cores_4_ports_2_lb_1_sw.conf } Baremetal @@ -266,5 +304,3 @@ To enable multiple queue set the queues_per_port value in the TG VNF options sec options: tg_0: queues_per_port: 2 - - diff --git a/docs/testing/user/userguide/code/multi-devstack-compute-local.conf b/docs/testing/user/userguide/code/multi-devstack-compute-local.conf new file mode 100644 index 000000000..b0b3cc5d4 --- /dev/null +++ b/docs/testing/user/userguide/code/multi-devstack-compute-local.conf @@ -0,0 +1,53 @@ +[[local|localrc]] +HOST_IP=<HOST_IP_ADDRESS> +MYSQL_PASSWORD=password +DATABASE_PASSWORD=password +RABBIT_PASSWORD=password +ADMIN_PASSWORD=password +SERVICE_PASSWORD=password +HORIZON_PASSWORD=password +# Controller node +SERVICE_HOST=<CONTROLLER_IP_ADDRESS> +MYSQL_HOST=$SERVICE_HOST +RABBIT_HOST=$SERVICE_HOST +GLANCE_HOSTPORT=$SERVICE_HOST:9292 + +# Internet access. +RECLONE=False +PIP_UPGRADE=True +IP_VERSION=4 + +# Neutron +enable_plugin neutron https://git.openstack.org/openstack/neutron.git stable/pike + +# Services +ENABLED_SERVICES=n-cpu,rabbit,q-agt,placement-api,q-sriov-agt + +# Neutron Options +PUBLIC_INTERFACE=<PUBLIC INTERFACE> + +# ML2 Configuration +Q_PLUGIN=ml2 +Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch,sriovnicswitch +Q_ML2_PLUGIN_TYPE_DRIVERS=vlan,flat,local,vxlan,gre,geneve + +# Open vSwitch provider networking configuration +PHYSICAL_DEVICE_MAPPINGS=physnet1:<PF0_IFNAME>,physnet2:<PF1_IFNAME> + + +[[post-config|$NOVA_CONF]] +[DEFAULT] +scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter +# Whitelist PCI devices +pci_passthrough_whitelist = {\\"devname\\": \\"<PF0_IFNAME>\\", \\"physical_network\\": \\"physnet1\\" } +pci_passthrough_whitelist = {\\"devname\\": \\"<PF1_IFNAME>\\", \\"physical_network\\": \\"physnet2\\" } + +[libvirt] +cpu_mode = host-model + + +# ML2 plugin bits for SR-IOV enablement of Intel Corporation XL710/X710 Virtual Function +[[post-config|/$Q_PLUGIN_CONF_FILE]] +[ml2_sriov] +agent_required = True +supported_pci_vendor_devs = <VF_DEV_ID:VF_VEN_ID> diff --git a/docs/testing/user/userguide/code/multi-devstack-controller-local.conf b/docs/testing/user/userguide/code/multi-devstack-controller-local.conf new file mode 100644 index 000000000..fb61cdcbd --- /dev/null +++ b/docs/testing/user/userguide/code/multi-devstack-controller-local.conf @@ -0,0 +1,64 @@ +[[local|localrc]] +HOST_IP=<HOST_IP_ADDRESS> +ADMIN_PASSWORD=password +MYSQL_PASSWORD=$ADMIN_PASSWORD +DATABASE_PASSWORD=$ADMIN_PASSWORD +RABBIT_PASSWORD=$ADMIN_PASSWORD +SERVICE_PASSWORD=$ADMIN_PASSWORD +HORIZON_PASSWORD=$ADMIN_PASSWORD +# Controller node +SERVICE_HOST=$HOST_IP +MYSQL_HOST=$SERVICE_HOST +RABBIT_HOST=$SERVICE_HOST +GLANCE_HOSTPORT=$SERVICE_HOST:9292 + +# Internet access. +RECLONE=False +PIP_UPGRADE=True +IP_VERSION=4 + +# Services +disable_service n-net +ENABLED_SERVICES+=,q-svc,q-dhcp,q-meta,q-agt,q-sriov-agt + +# Heat +enable_plugin heat https://git.openstack.org/openstack/heat stable/pike + +# Neutron +enable_plugin neutron https://git.openstack.org/openstack/neutron.git stable/pike + +# Neutron Options +FLOATING_RANGE=<RANGE_IN_THE_PUBLIC_INTERFACE_NETWORK> +Q_FLOATING_ALLOCATION_POOL=start=<START_IP_ADDRESS>,end=<END_IP_ADDRESS> +PUBLIC_NETWORK_GATEWAY=<PUBLIC_NETWORK_GATEWAY> +PUBLIC_INTERFACE=<PUBLIC INTERFACE> + +# ML2 Configuration +Q_PLUGIN=ml2 +Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch,sriovnicswitch +Q_ML2_PLUGIN_TYPE_DRIVERS=vlan,flat,local,vxlan,gre,geneve + +# Open vSwitch provider networking configuration +Q_USE_PROVIDERNET_FOR_PUBLIC=True +OVS_PHYSICAL_BRIDGE=br-ex +OVS_BRIDGE_MAPPINGS=public:br-ex +PHYSICAL_DEVICE_MAPPINGS=physnet1:<PF0_IFNAME>,physnet2:<PF1_IFNAME> +PHYSICAL_NETWORK=physnet1,physnet2 + + +[[post-config|$NOVA_CONF]] +[DEFAULT] +scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter +# Whitelist PCI devices +pci_passthrough_whitelist = {\\"devname\\": \\"<PF0_IFNAME>\\", \\"physical_network\\": \\"physnet1\\" } +pci_passthrough_whitelist = {\\"devname\\": \\"<PF1_IFNAME>\\", \\"physical_network\\": \\"physnet2\\" } + +[libvirt] +cpu_mode = host-model + + +# ML2 plugin bits for SR-IOV enablement of Intel Corporation XL710/X710 Virtual Function +[[post-config|/$Q_PLUGIN_CONF_FILE]] +[ml2_sriov] +agent_required = True +supported_pci_vendor_devs = <VF_DEV_ID:VF_VEN_ID> diff --git a/docs/testing/user/userguide/code/single-devstack-local.conf b/docs/testing/user/userguide/code/single-devstack-local.conf new file mode 100644 index 000000000..4c44f729d --- /dev/null +++ b/docs/testing/user/userguide/code/single-devstack-local.conf @@ -0,0 +1,62 @@ +[[local|localrc]] +HOST_IP=<HOST_IP_ADDRESS> +ADMIN_PASSWORD=password +MYSQL_PASSWORD=$ADMIN_PASSWORD +DATABASE_PASSWORD=$ADMIN_PASSWORD +RABBIT_PASSWORD=$ADMIN_PASSWORD +SERVICE_PASSWORD=$ADMIN_PASSWORD +HORIZON_PASSWORD=$ADMIN_PASSWORD + +# Internet access. +RECLONE=False +PIP_UPGRADE=True +IP_VERSION=4 + +# Services +disable_service n-net +ENABLED_SERVICES+=,q-svc,q-dhcp,q-meta,q-agt,q-sriov-agt + +# Heat +enable_plugin heat https://git.openstack.org/openstack/heat stable/pike + +# Neutron +enable_plugin neutron https://git.openstack.org/openstack/neutron.git stable/pike + +# Neutron Options +FLOATING_RANGE=<RANGE_IN_THE_PUBLIC_INTERFACE_NETWORK> +Q_FLOATING_ALLOCATION_POOL=start=<START_IP_ADDRESS>,end=<END_IP_ADDRESS> +PUBLIC_NETWORK_GATEWAY=<PUBLIC_NETWORK_GATEWAY> +PUBLIC_INTERFACE=<PUBLIC INTERFACE> + +# ML2 Configuration +Q_PLUGIN=ml2 +Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch,sriovnicswitch +Q_ML2_PLUGIN_TYPE_DRIVERS=vlan,flat,local,vxlan,gre,geneve + +# Open vSwitch provider networking configuration +Q_USE_PROVIDERNET_FOR_PUBLIC=True +OVS_PHYSICAL_BRIDGE=br-ex +OVS_BRIDGE_MAPPINGS=public:br-ex +PHYSICAL_DEVICE_MAPPINGS=physnet1:<PF0_IFNAME>,physnet2:<PF1_IFNAME> +PHYSICAL_NETWORK=physnet1,physnet2 + + +[[post-config|$NOVA_CONF]] +[DEFAULT] +scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter +# Whitelist PCI devices +pci_passthrough_whitelist = {\\"devname\\": \\"<PF0_IFNAME>\\", \\"physical_network\\": \\"physnet1\\" } +pci_passthrough_whitelist = {\\"devname\\": \\"<PF1_IFNAME>\\", \\"physical_network\\": \\"physnet2\\" } + +[filter_scheduler] +enabled_filters = RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter + +[libvirt] +cpu_mode = host-model + + +# ML2 plugin bits for SR-IOV enablement of Intel Corporation XL710/X710 Virtual Function +[[post-config|/$Q_PLUGIN_CONF_FILE]] +[ml2_sriov] +agent_required = True +supported_pci_vendor_devs = <VF_DEV_ID:VF_VEN_ID> diff --git a/docs/testing/user/userguide/code/single-yardstick-pod.conf b/docs/testing/user/userguide/code/single-yardstick-pod.conf new file mode 100644 index 000000000..421246d60 --- /dev/null +++ b/docs/testing/user/userguide/code/single-yardstick-pod.conf @@ -0,0 +1,22 @@ +nodes: +- + name: trafficgen_1 + role: tg__0 + ip: <TG-HOST-IP> + user: <TG-USER> + password: <TG-PASS> + interfaces: + xe0: # logical name from topology.yaml and vnfd.yaml + vpci: "0000:18:00.0" + driver: i40e # default kernel driver + dpdk_port_num: 0 + local_ip: "10.1.1.150" + netmask: "255.255.255.0" + local_mac: "00:00:00:00:00:01" + xe1: # logical name from topology.yaml and vnfd.yaml + vpci: "0000:18:00.1" + driver: i40e # default kernel driver + dpdk_port_num: 1 + local_ip: "10.1.1.151" + netmask: "255.255.255.0" + local_mac: "00:00:00:00:00:02" diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc019.rst b/docs/testing/user/userguide/opnfv_yardstick_tc019.rst index 57e8ddf79..8d79e011a 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc019.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc019.rst @@ -125,7 +125,12 @@ Yardstick Test Case Description TC019 +--------------+--------------------------------------------------------------+ |post-action | It is the action when the test cases exist. It will check | | | the status of the specified process on the host, and restart | -| | the process if it is not running for next test cases | +| | the process if it is not running for next test cases. | +| | | +| | Notice: This post-action uses 'lsb_release' command to check | +| | the host linux distribution and determine the OpenStack | +| | service name to restart the process. Lack of 'lsb_release' | +| | on the host may cause failure to restart the process. | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc045.rst b/docs/testing/user/userguide/opnfv_yardstick_tc045.rst index 0b0993c34..378176090 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc045.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc045.rst @@ -128,9 +128,14 @@ Yardstick Test Case Description TC045 | | Result: The test case is passed or not. | | | | +--------------+--------------------------------------------------------------+ -|post-action | It is the action when the test cases exist. It will check the| -| | status of the specified process on the host, and restart the | -| | process if it is not running for next test cases | +|post-action | It is the action when the test cases exist. It will check | +| | the status of the specified process on the host, and restart | +| | the process if it is not running for next test cases. | +| | | +| | Notice: This post-action uses 'lsb_release' command to check | +| | the host linux distribution and determine the OpenStack | +| | service name to restart the process. Lack of 'lsb_release' | +| | on the host may cause failure to restart the process. | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc046.rst b/docs/testing/user/userguide/opnfv_yardstick_tc046.rst index cce6c6884..5308c8e7b 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc046.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc046.rst @@ -127,9 +127,14 @@ Yardstick Test Case Description TC046 | | Result: The test case is passed or not. | | | | +--------------+--------------------------------------------------------------+ -|post-action | It is the action when the test cases exist. It will check the| -| | status of the specified process on the host, and restart the | -| | process if it is not running for next test cases | +|post-action | It is the action when the test cases exist. It will check | +| | the status of the specified process on the host, and restart | +| | the process if it is not running for next test cases. | +| | | +| | Notice: This post-action uses 'lsb_release' command to check | +| | the host linux distribution and determine the OpenStack | +| | service name to restart the process. Lack of 'lsb_release' | +| | on the host may cause failure to restart the process. | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc047.rst b/docs/testing/user/userguide/opnfv_yardstick_tc047.rst index 95158cfd6..bb8ffc6ab 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc047.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc047.rst @@ -128,9 +128,14 @@ Yardstick Test Case Description TC047 | | Result: The test case is passed or not. | | | | +--------------+--------------------------------------------------------------+ -|post-action | It is the action when the test cases exist. It will check the| -| | status of the specified process on the host, and restart the | -| | process if it is not running for next test cases | +|post-action | It is the action when the test cases exist. It will check | +| | the status of the specified process on the host, and restart | +| | the process if it is not running for next test cases. | +| | | +| | Notice: This post-action uses 'lsb_release' command to check | +| | the host linux distribution and determine the OpenStack | +| | service name to restart the process. Lack of 'lsb_release' | +| | on the host may cause failure to restart the process. | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc048.rst b/docs/testing/user/userguide/opnfv_yardstick_tc048.rst index 21c00d1fe..1bf627282 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc048.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc048.rst @@ -128,9 +128,14 @@ Yardstick Test Case Description TC048 | | Result: The test case is passed or not. | | | | +--------------+--------------------------------------------------------------+ -|post-action | It is the action when the test cases exist. It will check the| -| | status of the specified process on the host, and restart the | -| | process if it is not running for next test cases | +|post-action | It is the action when the test cases exist. It will check | +| | the status of the specified process on the host, and restart | +| | the process if it is not running for next test case | +| | | +| | Notice: This post-action uses 'lsb_release' command to check | +| | the host linux distribution and determine the OpenStack | +| | service name to restart the process. Lack of 'lsb_release' | +| | on the host may cause failure to restart the process. | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc049.rst b/docs/testing/user/userguide/opnfv_yardstick_tc049.rst index f58bb9989..12ed94b7d 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc049.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc049.rst @@ -128,9 +128,14 @@ Yardstick Test Case Description TC049 | | Result: The test case is passed or not. | | | | +--------------+--------------------------------------------------------------+ -|post-action | It is the action when the test cases exist. It will check the| -| | status of the specified process on the host, and restart the | -| | process if it is not running for next test cases | +|post-action | It is the action when the test cases exist. It will check | +| | the status of the specified process on the host, and restart | +| | the process if it is not running for next test cases. | +| | | +| | Notice: This post-action uses 'lsb_release' command to check | +| | the host linux distribution and determine the OpenStack | +| | service name to restart the process. Lack of 'lsb_release' | +| | on the host may cause failure to restart the process. | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc053.rst b/docs/testing/user/userguide/opnfv_yardstick_tc053.rst index 3c6bbc628..7308babb8 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc053.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc053.rst @@ -135,6 +135,11 @@ Yardstick Test Case Description TC053 | | the status of the specified process on the host, and restart | | | the process if it is not running for next test cases. | | | | +| | Notice: This post-action uses 'lsb_release' command to check | +| | the host linux distribution and determine the OpenStack | +| | service name to restart the process. Lack of 'lsb_release' | +| | on the host may cause failure to restart the process. | +| | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | | | execution problem. | diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc056.rst b/docs/testing/user/userguide/opnfv_yardstick_tc056.rst index 09b866c34..cd8cc2f20 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc056.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc056.rst @@ -142,6 +142,11 @@ Yardstick Test Case Description TC056 | | the status of the specified process on the host, and restart | | | the process if it is not running for next test cases. | | | | +| | Notice: This post-action uses 'lsb_release' command to check | +| | the host linux distribution and determine the OpenStack | +| | service name to restart the process. Lack of 'lsb_release' | +| | on the host may cause failure to restart the process. | +| | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | | | execution problem. | diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc057.rst b/docs/testing/user/userguide/opnfv_yardstick_tc057.rst index bb42b2aae..1bb43c9e7 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc057.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc057.rst @@ -162,8 +162,14 @@ Yardstick Test Case Description TC057 |post-action | It is the action when the test cases exist. It will check | | | the status of the cluster messaging process(corosync) on the | | | host, and restart the process if it is not running for next | -| | test cases | +| | test cases. | +| | Notice: This post-action uses 'lsb_release' command to check | +| | the host linux distribution and determine the OpenStack | +| | service name to restart the process. Lack of 'lsb_release' | +| | on the host may cause failure to restart the process. | +| | | +--------------+------+----------------------------------+--------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | | | execution problem. | +| | | +--------------+--------------------------------------------------------------+ diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc058.rst b/docs/testing/user/userguide/opnfv_yardstick_tc058.rst index 7c323e913..9e8427b50 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc058.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc058.rst @@ -109,8 +109,9 @@ Yardstick Test Case Description TC058 |conditions | with cachestat included in the image. | | | | +--------------+--------------------------------------------------------------+ -|step 1 | Two host VMs are booted, these two hosts are in two different| -| | networks, the networks are connected by a virtual router | +|step 1 | Two host VMs are booted, these two hosts are in two | +| | different networks, the networks are connected by a virtual | +| | router. | | | | +--------------+--------------------------------------------------------------+ |step 1 | start monitors: | @@ -143,7 +144,13 @@ Yardstick Test Case Description TC058 | | Virtual machines and network created in the test case will | | | be destoryed. | | | | +| | Notice: This post-action uses 'lsb_release' command to check | +| | the host linux distribution and determine the OpenStack | +| | service name to restart the process. Lack of 'lsb_release' | +| | on the host may cause failure to restart the process. | +| | | +--------------+------+----------------------------------+--------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | | | execution problem. | +| | | +--------------+--------------------------------------------------------------+ diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc090.rst b/docs/testing/user/userguide/opnfv_yardstick_tc090.rst new file mode 100644 index 000000000..1f8747b2b --- /dev/null +++ b/docs/testing/user/userguide/opnfv_yardstick_tc090.rst @@ -0,0 +1,151 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, Yin Kanglin and others. +.. 14_ykl@tongji.edu.cn + +************************************* +Yardstick Test Case Description TC090 +************************************* + ++-----------------------------------------------------------------------------+ +|Control Node OpenStack Service High Availability - Database Instances | +| | ++--------------+--------------------------------------------------------------+ +|test case id | OPNFV_YARDSTICK_TC090: Control node OpenStack service down - | +| | database instances | ++--------------+--------------------------------------------------------------+ +|test purpose | This test case will verify the high availability of the | +| | data base instances used by OpenStack (mysql) on control | +| | node. | +| | | ++--------------+--------------------------------------------------------------+ +|test method | This test case kills the processes of database service on a | +| | selected control node, then checks whether the request of | +| | the related OpenStack command is OK and the killed processes | +| | are recovered. | +| | | ++--------------+--------------------------------------------------------------+ +|attackers | In this test case, an attacker called "kill-process" is | +| | needed. This attacker includes three parameters: | +| | 1) fault_type: which is used for finding the attacker's | +| | scripts. It should be always set to "kill-process" in this | +| | test case. | +| | 2) process_name: which is the process name of the specified | +| | OpenStack service. If there are multiple processes use the | +| | same name on the host, all of them are killed by this | +| | attacker. | +| | In this case. This parameter should always set to the name | +| | of the database service of OpenStack. | +| | 3) host: which is the name of a control node being attacked. | +| | | +| | e.g. | +| | -fault_type: "kill-process" | +| | -process_name: "mysql" | +| | -host: node1 | +| | | ++--------------+--------------------------------------------------------------+ +|monitors | In this test case, two kinds of monitor are needed: | +| | 1. the "openstack-cmd" monitor constantly request a specific | +| | Openstack command, which needs two parameters: | +| | 1) monitor_type: which is used for finding the monitor class | +| | and related scritps. It should be always set to | +| | "openstack-cmd" for this monitor. | +| | 2) command_name: which is the command name used for request. | +| | In this case, the command name should be neutron related | +| | commands. | +| | | +| | 2. the "process" monitor check whether a process is running | +| | on a specific node, which needs three parameters: | +| | 1) monitor_type: which used for finding the monitor class and| +| | related scripts. It should be always set to "process" | +| | for this monitor. | +| | 2) process_name: which is the process name for monitor | +| | 3) host: which is the name of the node running the process | +| | | +| | The examples of monitors show as follows, there are four | +| | instance of the "openstack-cmd" monitor, in order to check | +| | the database connection of different OpenStack components. | +| | | +| | monitor1: | +| | -monitor_type: "openstack-cmd" | +| | -api_name: "openstack image list" | +| | monitor2: | +| | -monitor_type: "openstack-cmd" | +| | -api_name: "openstack router list" | +| | monitor3: | +| | -monitor_type: "openstack-cmd" | +| | -api_name: "openstack stack list" | +| | monitor4: | +| | -monitor_type: "openstack-cmd" | +| | -api_name: "openstack volume list" | +| | monitor5: | +| | -monitor_type: "process" | +| | -process_name: "mysql" | +| | -host: node1 | +| | | ++--------------+--------------------------------------------------------------+ +|metrics | In this test case, there are two metrics: | +| | 1)service_outage_time: which indicates the maximum outage | +| | time (seconds) of the specified OpenStack command request. | +| | 2)process_recover_time: which indicates the maximum time | +| | (seconds) from the process being killed to recovered | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | Developed by the project. Please see folder: | +| | "yardstick/benchmark/scenarios/availability/ha_tools" | +| | | ++--------------+--------------------------------------------------------------+ +|references | ETSI NFV REL001 | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | This test case needs two configuration files: | +| | 1) test case file: opnfv_yardstick_tc090.yaml | +| | -Attackers: see above "attackers" description | +| | -waiting_time: which is the time (seconds) from the process | +| | being killed to stopping monitors the monitors | +| | -Monitors: see above "monitors" description | +| | -SLA: see above "metrics" description | +| | | +| | 2)POD file: pod.yaml | +| | The POD configuration should record on pod.yaml first. | +| | the "host" item in this test case will use the node name in | +| | the pod.yaml. | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | start monitors: | +| | each monitor will run with independently process | +| | | +| | Result: The monitor info will be collected. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | do attacker: connect the host through SSH, and then execute | +| | the kill process script with param value specified by | +| | "process_name" | +| | | +| | Result: Process will be killed. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | stop monitors after a period of time specified by | +| | "waiting_time" | +| | | +| | Result: The monitor info will be aggregated. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | verify the SLA | +| | | +| | Result: The test case is passed or not. | +| | | ++--------------+--------------------------------------------------------------+ +|post-action | It is the action when the test cases exist. It will check the| +| | status of the specified process on the host, and restart the | +| | process if it is not running for next test cases | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | Fails only if SLA is not passed, or if there is a test case | +| | execution problem. | +| | | ++--------------+--------------------------------------------------------------+ diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc091.rst b/docs/testing/user/userguide/opnfv_yardstick_tc091.rst new file mode 100644 index 000000000..8e89b6425 --- /dev/null +++ b/docs/testing/user/userguide/opnfv_yardstick_tc091.rst @@ -0,0 +1,138 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, Yin Kanglin and others. +.. 14_ykl@tongji.edu.cn + +************************************* +Yardstick Test Case Description TC091 +************************************* + ++-----------------------------------------------------------------------------+ +|Control Node Openstack Service High Availability - Heat Api | +| | ++--------------+--------------------------------------------------------------+ +|test case id | OPNFV_YARDSTICK_TC091: Control node OpenStack service down - | +| | heat api | ++--------------+--------------------------------------------------------------+ +|test purpose | This test case will verify the high availability of the | +| | orchestration service provided by OpenStack (heat-api) on | +| | control node. | +| | | ++--------------+--------------------------------------------------------------+ +|test method | This test case kills the processes of heat-api service on a | +| | selected control node, then checks whether the request of | +| | the related OpenStack command is OK and the killed processes | +| | are recovered. | +| | | ++--------------+--------------------------------------------------------------+ +|attackers | In this test case, an attacker called "kill-process" is | +| | needed. This attacker includes three parameters: | +| | 1) fault_type: which is used for finding the attacker's | +| | scripts. It should be always set to "kill-process" in this | +| | test case. | +| | 2) process_name: which is the process name of the specified | +| | OpenStack service. If there are multiple processes use the | +| | same name on the host, all of them are killed by this | +| | attacker. | +| | In this case. This parameter should always set to "heat-api".| +| | 3) host: which is the name of a control node being attacked. | +| | | +| | e.g. | +| | -fault_type: "kill-process" | +| | -process_name: "heat-api" | +| | -host: node1 | +| | | ++--------------+--------------------------------------------------------------+ +|monitors | In this test case, two kinds of monitor are needed: | +| | 1. the "openstack-cmd" monitor constantly request a specific | +| | OpenStack command, which needs two parameters: | +| | 1) monitor_type: which is used for finding the monitor class | +| | and related scripts. It should be always set to | +| | "openstack-cmd" for this monitor. | +| | 2) command_name: which is the command name used for request. | +| | In this case, the command name should be neutron related | +| | commands. | +| | | +| | 2. the "process" monitor check whether a process is running | +| | on a specific node, which needs three parameters: | +| | 1) monitor_type: which used for finding the monitor class and| +| | related scripts. It should be always set to "process" | +| | for this monitor. | +| | 2) process_name: which is the process name for monitor | +| | 3) host: which is the name of the node running the process | +| | | +| | e.g. | +| | monitor1: | +| | -monitor_type: "openstack-cmd" | +| | -command_name: "heat stack list" | +| | monitor2: | +| | -monitor_type: "process" | +| | -process_name: "heat-api" | +| | -host: node1 | +| | | ++--------------+--------------------------------------------------------------+ +|metrics | In this test case, there are two metrics: | +| | 1)service_outage_time: which indicates the maximum outage | +| | time (seconds) of the specified OpenStack command request. | +| | 2)process_recover_time: which indicates the maximum time | +| | (seconds) from the process being killed to recovered | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | Developed by the project. Please see folder: | +| | "yardstick/benchmark/scenarios/availability/ha_tools" | +| | | ++--------------+--------------------------------------------------------------+ +|references | ETSI NFV REL001 | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | This test case needs two configuration files: | +| | 1) test case file: opnfv_yardstick_tc091.yaml | +| | -Attackers: see above "attackers" description | +| | -waiting_time: which is the time (seconds) from the process | +| | being killed to the monitor stopped | +| | -Monitors: see above "monitors" description | +| | -SLA: see above "metrics" description | +| | | +| | 2)POD file: pod.yaml | +| | The POD configuration should record on pod.yaml first. | +| | the "host" item in this test case will use the node name in | +| | the pod.yaml. | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | start monitors: | +| | each monitor will run with independently process | +| | | +| | Result: The monitor info will be collected. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | do attacker: connect the host through SSH, and then execute | +| | the kill process script with param value specified by | +| | "process_name" | +| | | +| | Result: Process will be killed. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | stop monitors after a period of time specified by | +| | "waiting_time" | +| | | +| | Result: The monitor info will be aggregated. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | verify the SLA | +| | | +| | Result: The test case is passed or not. | +| | | ++--------------+--------------------------------------------------------------+ +|post-action | It is the action when the test cases exist. It will check the| +| | status of the specified process on the host, and restart the | +| | process if it is not running for next test cases | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | Fails only if SLA is not passed, or if there is a test case | +| | execution problem. | +| | | ++--------------+--------------------------------------------------------------+ |