diff options
Diffstat (limited to 'docs/testing')
26 files changed, 3830 insertions, 1133 deletions
diff --git a/docs/testing/developer/devguide/devguide.rst b/docs/testing/developer/devguide/devguide.rst index 238fbd93c..dade49b75 100644..100755 --- a/docs/testing/developer/devguide/devguide.rst +++ b/docs/testing/developer/devguide/devguide.rst @@ -63,6 +63,256 @@ How Yardstick works? The installation and configuration of the Yardstick is described in the `user guide`_. +How to work with test cases? +---------------------------- + + +**Sample Test cases** + +Yardstick provides many sample test cases which are located at "samples" directory of repo. + +Sample test cases are designed as following goals: + +1. Helping user better understand yardstick features(including new feature and new test capacity). + +2. Helping developer to debug his new feature and test case before it is offical released. + +3. Helping other developers understand and verify the new patch before the patch merged. + +So developers should upload your sample test case as well when they are trying to upload a new patch which is about the yardstick new test case or new feature. + + +**OPNFV Release Test cases** + +OPNFV Release test cases which are located at "tests/opnfv/test_cases" of repo. +those test cases are runing by OPNFV CI jobs, It means those test cases should be more mature than sample test cases. +OPNFV scenario owners can select related test cases and add them into the test suites which is represent the scenario. + + +**Test case Description File** + +This section will introduce the meaning of the Test case description file. +we will use ping.yaml as a example to show you how to understand the test case description file. +In this Yaml file, you can easily find it consists of two sections. One is “Scenarios”, the other is “Context”.:: + + --- + # Sample benchmark task config file + # measure network latency using ping + + schema: "yardstick:task:0.1" + + {% set provider = provider or none %} + {% set physical_network = physical_network or 'physnet1' %} + {% set segmentation_id = segmentation_id or none %} + scenarios: + - + type: Ping + options: + packetsize: 200 + host: athena.demo + target: ares.demo + + runner: + type: Duration + duration: 60 + interval: 1 + + sla: + max_rtt: 10 + action: monitor + + context: + name: demo + image: yardstick-image + flavor: yardstick-flavor + user: ubuntu + + placement_groups: + pgrp1: + policy: "availability" + + servers: + athena: + floating_ip: true + placement: "pgrp1" + ares: + placement: "pgrp1" + + networks: + test: + cidr: '10.0.1.0/24' + {% if provider == "vlan" %} + provider: {{provider}} + physical_network: {{physical_network}} + {% if segmentation_id %} + segmentation_id: {{segmentation_id}} + {% endif %} + {% endif %} + + +"Contexts" section is the description of pre-condition of testing. As ping.yaml shown, you can configure the image, flavor , name ,affinity and network of Test VM(servers), with this section, you will get a pre-condition env for Testing. +Yardstick will automatic setup the stack which are described in this section. +In fact, yardstick use convert this section to heat template and setup the VMs by heat-client (Meanwhile, yardstick can support to convert this section to Kubernetes template to setup containers). + +Two Test VMs(athena and ares) are configured by keyword "servers". +"flavor" will determine how many vCPU, how much memory for test VMs. +As "yardstick-flavor" is a basic flavor which will be automatically created when you run command "yardstick env prepare". "yardstick-flavor" is "1 vCPU 1G RAM,3G Disk". +"image" is the image name of test VMs. if you use cirros.3.5.0, you need fill the username of this image into "user". the "policy" of placement of Test VMs have two values (affinity and availability). +"availability" means anti-affinity. In "network" section, you can configure which provide network and physical_network you want Test VMs use. +you may need to configure segmentation_id when your network is vlan. + +Moreover, you can configure your specific flavor as below, yardstick will setup the stack for you. :: + + flavor: + name: yardstick-new-flavor + vcpus: 12 + ram: 1024 + disk: 2 + + +Besides default heat stack, yardstick also allow you to setup other two types stack. they are "Node" and "Kubernetes". :: + + context: + type: Kubernetes + name: k8s + +and :: + + context: + type: Node + name: LF + + + +"Scenarios" section is the description of testing step, you can orchestrate the complex testing step through orchestrate scenarios. + +Each scenario will do one testing step, In one scenario, you can configure the type of scenario(operation), runner type and SLA of the scenario. + +For TC002, We only have one step , that is Ping from host VM to target VM. In this step, we also have some detail operation implement ( such as ssh to VM, ping from VM1 to VM2. Get the latency, verify the SLA, report the result). + +If you want to get this detail implement , you can check with the scenario.py file. For Ping scenario, you can find it in yardstick repo ( yardstick / yardstick / benchmark / scenarios / networking / ping.py) + +after you select the type of scenario( such as Ping), you will select one type of runner, there are 4 types of runner. Usually, we use the "Iteration" and "Duration". and Default is "Iteration". +For Iteration, you can specify the iteration number and interval of iteration. :: + + runner: + type: Iteration + iterations: 10 + interval: 1 + +That means yardstick will iterate the 10 times of Ping test and the interval of each iteration is one second. + +For Duration, you can specify the duration of this scenario and the interval of each ping test. :: + + runner: + type: Duration + duration: 60 + interval: 10 + +That means yardstick will run the ping test as loop until the total time of this scenario reach the 60s and the interval of each loop is ten seconds. + + +SLA is the criterion of this scenario. that depends on the scenario. different scenario can have different SLA metric. + + +**How to write a new test case** + +Yardstick already provide a library of testing step. that means yardstick provide lots of type scenario. + +Basiclly, What you need to do is to orchestrate the scenario from the library. + +Here, We will show two cases. One is how to write a simple test case, the other is how to write a quite complex test case. + + +Write a new simple test case + +First, you can image a basic test case description as below. + ++-----------------------------------------------------------------------------+ +|Storage Performance | +| | ++--------------+--------------------------------------------------------------+ +|metric | IOPS (Average IOs performed per second), | +| | Throughput (Average disk read/write bandwidth rate), | +| | Latency (Average disk read/write latency) | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The purpose of TC005 is to evaluate the IaaS storage | +| | performance with regards to IOPS, throughput and latency. | +| | | ++--------------+--------------------------------------------------------------+ +|test | fio test is invoked in a host VM on a compute blade, a job | +|description | file as well as parameters are passed to fio and fio will | +| | start doing what the job file tells it to do. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | file: opnfv_yardstick_tc005.yaml | +| | | +| | IO types is set to read, write, randwrite, randread, rw. | +| | IO block size is set to 4KB, 64KB, 1024KB. | +| | fio is run for each IO type and IO block size scheme, | +| | each iteration runs for 30 seconds (10 for ramp time, 20 for | +| | runtime). | +| | | +| | For SLA, minimum read/write iops is set to 100, | +| | minimum read/write throughput is set to 400 KB/s, | +| | and maximum read/write latency is set to 20000 usec. | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | This test case can be configured with different: | +| | | +| | * IO types; | +| | * IO block size; | +| | * IO depth; | +| | * ramp time; | +| | * test duration. | +| | | +| | Default values exist. | +| | | +| | SLA is optional. The SLA in this test case serves as an | +| | example. Considerably higher throughput and lower latency | +| | are expected. However, to cover most configurations, both | +| | baremetal and fully virtualized ones, this value should be | +| | possible to achieve and acceptable for black box testing. | +| | Many heavy IO applications start to suffer badly if the | +| | read/write bandwidths are lower than this. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | The test case image needs to be installed into Glance | +|conditions | with fio included in it. | +| | | +| | No POD specific requirements have been identified. | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | A host VM with fio installed is booted. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the host VM by using ssh. | +| | 'fio_benchmark' bash script is copyied from Jump Host to | +| | the host VM via the ssh tunnel. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | 'fio_benchmark' script is invoked. Simulated IO operations | +| | are started. IOPS, disk read/write bandwidth and latency are | +| | recorded and checked against the SLA. Logs are produced and | +| | stored. | +| | | +| | Result: Logs are stored. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | The host VM is deleted. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | Fails only if SLA is not passed, or if there is a test case | +| | execution problem. | +| | | ++--------------+--------------------------------------------------------------+ + +TODO + How can I contribute to Yardstick? ----------------------------------- @@ -111,7 +361,7 @@ Verify your patch locally before submitting Once you finish a patch, you can submit it to Gerrit for code review. A developer sends a new patch to Gerrit will trigger patch verify job on Jenkins -CI. The yardstick patch verify job includes python flake8 check, unit test and +CI. The yardstick patch verify job includes python pylint check, unit test and code coverage test. Before you submit your patch, it is recommended to run the patch verification in your local environment first. @@ -122,7 +372,7 @@ directory using the ``cd`` command. Assume that ``YARDSTICK_REPO_DIR`` is the pa Verify your patch:: - ./run_tests.sh + tox It is used in CI but also by the CLI. diff --git a/docs/testing/developer/devguide/index.rst b/docs/testing/developer/devguide/index.rst index fc3ca155d..92a18f6ee 100644 --- a/docs/testing/developer/devguide/index.rst +++ b/docs/testing/developer/devguide/index.rst @@ -5,9 +5,9 @@ .. http://creativecommons.org/licenses/by/4.0 .. (c) OPNFV, Ericsson AB and others. -********************************* -OPNFV Yardstick developer guide -********************************* +************************* +Yardstick Developer Guide +************************* .. toctree:: :maxdepth: 4 diff --git a/docs/testing/user/userguide/04-installation.rst b/docs/testing/user/userguide/04-installation.rst index b40e1143e..828c49581 100644 --- a/docs/testing/user/userguide/04-installation.rst +++ b/docs/testing/user/userguide/04-installation.rst @@ -3,13 +3,11 @@ .. http://creativecommons.org/licenses/by/4.0 .. (c) OPNFV, Ericsson AB, Huawei Technologies Co.,Ltd and others. +====================== Yardstick Installation ====================== -Abstract --------- - Yardstick supports installation by Docker or directly in Ubuntu. The installation procedure for Docker and direct installation are detailed in the sections below. @@ -21,126 +19,130 @@ The steps needed to run Yardstick are: 1. Install Yardstick. 2. Load OpenStack environment variables. -#. Create Yardstick flavor. -#. Build a guest image and load it into the OpenStack environment. -#. Create the test configuration ``.yaml`` file and run the test case/suite. +3. Create Yardstick flavor. +4. Build a guest image and load it into the OpenStack environment. +5. Create the test configuration ``.yaml`` file and run the test case/suite. Prerequisites ------------- -The OPNFV deployment is out of the scope of this document and can be found `here <http://artifacts.opnfv.org/opnfvdocs/colorado/docs/configguide/index.html>`_. The OPNFV platform is considered as the System Under Test (SUT) in this document. +The OPNFV deployment is out of the scope of this document and can be found in +`User Guide & Configuration Guide`_. The OPNFV platform is considered as the +System Under Test (SUT) in this document. Several prerequisites are needed for Yardstick: -#. A Jumphost to run Yardstick on -#. A Docker daemon or a virtual environment installed on the Jumphost -#. A public/external network created on the SUT -#. Connectivity from the Jumphost to the SUT public/external network +1. A Jumphost to run Yardstick on +2. A Docker daemon or a virtual environment installed on the Jumphost +3. A public/external network created on the SUT +4. Connectivity from the Jumphost to the SUT public/external network -**NOTE:** *Jumphost* refers to any server which meets the previous +.. note:: *Jumphost* refers to any server which meets the previous requirements. Normally it is the same server from where the OPNFV deployment has been triggered. -**WARNING:** Connectivity from Jumphost is essential and it is of paramount +.. warning:: Connectivity from Jumphost is essential and it is of paramount importance to make sure it is working before even considering to install and run Yardstick. Make also sure you understand how your networking is designed to work. -**NOTE:** If your Jumphost is operating behind a company http proxy and/or -Firewall, please consult first the section `Proxy Support (**Todo**)`_, towards -the end of this document. That section details some tips/tricks which -*may* be of help in a proxified environment. +.. note:: If your Jumphost is operating behind a company http proxy and/or +Firewall, please first consult `Proxy Support`_ section which is towards the +end of this document. That section details some tips/tricks which *may* be of +help in a proxified environment. -Install Yardstick using Docker (**recommended**) ---------------------------------------------------- +Install Yardstick using Docker (first option) (**recommended**) +--------------------------------------------------------------- -Yardstick has a Docker image. It is recommended to use this Docker image to run Yardstick test. +Yardstick has a Docker image. It is recommended to use this Docker image to run +Yardstick test. Prepare the Yardstick container -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. _dockerhub: https://hub.docker.com/r/opnfv/yardstick/ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Install docker on your guest system with the following command, if not done yet:: +Install docker on your guest system with the following command, if not done +yet:: - wget -qO- https://get.docker.com/ | sh + wget -qO- https://get.docker.com/ | sh Pull the Yardstick Docker image (``opnfv/yardstick``) from the public dockerhub -registry under the OPNFV account: dockerhub_, with the following docker +registry under the OPNFV account in dockerhub_, with the following docker command:: - docker pull opnfv/yardstick:stable + sudo -EH docker pull opnfv/yardstick:stable After pulling the Docker image, check that it is available with the following docker command:: - [yardsticker@jumphost ~]$ docker images - REPOSITORY TAG IMAGE ID CREATED SIZE - opnfv/yardstick stable a4501714757a 1 day ago 915.4 MB + [yardsticker@jumphost ~]$ docker images + REPOSITORY TAG IMAGE ID CREATED SIZE + opnfv/yardstick stable a4501714757a 1 day ago 915.4 MB Run the Docker image to get a Yardstick container:: - docker run -itd --privileged -v /var/run/docker.sock:/var/run/docker.sock -p 8888:5000 --name yardstick opnfv/yardstick:stable - -Note: - -+----------------------------------------------+------------------------------+ -| parameters | Detail | -+==============================================+==============================+ -| -itd | -i: interactive, Keep STDIN | -| | open even if not attached. | -| | -t: allocate a pseudo-TTY. | -| | -d: run container in | -| | detached mode, in the | -| | background. | -+----------------------------------------------+------------------------------+ -| --privileged | If you want to build | -| | ``yardstick-image`` in | -| | Yardstick container, this | -| | parameter is needed. | -+----------------------------------------------+------------------------------+ -| -p 8888:5000 | If you want to call | -| | Yardstick API out of | -| | Yardstick container, this | -| | parameter is needed. | -+----------------------------------------------+------------------------------+ -| -v /var/run/docker.sock:/var/run/docker.sock | If you want to use yardstick | -| | env grafana/influxdb to | -| | create a grafana/influxdb | -| | container out of Yardstick | -| | container, this parameter is | -| | needed. | -+----------------------------------------------+------------------------------+ -| --name yardstick | The name for this container, | -| | not needed and can be | -| | defined by the user. | -+----------------------------------------------+------------------------------+ + docker run -itd --privileged -v /var/run/docker.sock:/var/run/docker.sock \ + -p 8888:5000 --name yardstick opnfv/yardstick:stable + +.. table:: Description of the parameters used with ``docker run`` command + + ======================= ==================================================== + Parameters Detail + ======================= ==================================================== + -itd -i: interactive, Keep STDIN open even if not + attached + -t: allocate a pseudo-TTY detached mode, in the + background + ======================= ==================================================== + --privileged If you want to build ``yardstick-image`` in + Yardstick container, this parameter is needed + ======================= ==================================================== + -p 8888:5000 Redirect the a host port (8888) to a container port + (5000) + ======================= ==================================================== + -v /var/run/docker.sock If you want to use yardstick env grafana/influxdb to + :/var/run/docker.sock create a grafana/influxdb container out of Yardstick + container + ======================= ==================================================== + --name yardstick The name for this container + Configure the Yardstick container environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -There are three ways to configure environments for running Yardstick, which will be shown in the following sections. Before that, enter the Yardstick container:: +There are three ways to configure environments for running Yardstick, explained +in the following sections. Before that, access the Yardstick container:: - docker exec -it yardstick /bin/bash + docker exec -it yardstick /bin/bash and then configure Yardstick environments in the Yardstick container. -The first way (**recommended**) -################################### +Using the CLI command ``env prepare`` (first way) (**recommended**) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the Yardstick container, the Yardstick repository is located in the +``/home/opnfv/repos`` directory. Yardstick provides a CLI to prepare OpenStack +environment variables and create Yardstick flavor and guest images +automatically:: -In the Yardstick container, the Yardstick repository is located in the ``/home/opnfv/repos`` directory. Yardstick provides a CLI to prepare OpenStack environment variables and create Yardstick flavor and guest images automatically:: + yardstick env prepare - yardstick env prepare +.. note:: Since Euphrates release, the above command will not be able to +automatically configure the ``/etc/yardstick/openstack.creds`` file. So before +running the above command, it is necessary to create the +``/etc/yardstick/openstack.creds`` file and save OpenStack environment +variables into it manually. If you have the openstack credential file saved +outside the Yardstick Docker container, you can do this easily by mapping the +credential file into Yardstick container using:: -**NOTE**: Since Euphrates release, the above command will not able to automatically configure the /etc/yardstick/openstack.creds file. -So before running the above command, it is necessary to create the /etc/yardstick/openstack.creds file and save OpenStack environment variables into it manually. -If you have the openstack credential file saved outside the Yardstcik Docker container, you can do this easily by mapping the credential file into Yardstick container - using '-v /path/to/credential_file:/etc/yardstick/openstack.creds' when running the Yardstick container. -For details of the required OpenStack environment variables please refer to section **Export OpenStack environment variables** + '-v /path/to/credential_file:/etc/yardstick/openstack.creds' -The env prepare command may take up to 6-8 minutes to finish building +when running the Yardstick container. For details of the required OpenStack +environment variables please refer to section `Export OpenStack environment +variables`_. + +The ``env prepare`` command may take up to 6-8 minutes to finish building yardstick-image and other environment preparation. Meanwhile if you wish to monitor the env prepare process, you can enter the Yardstick container in a new terminal window and execute the following command:: @@ -148,25 +150,26 @@ terminal window and execute the following command:: tail -f /var/log/yardstick/uwsgi.log -The second way -################ +Manually exporting the env variables and initializing OpenStack (second way) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Export OpenStack environment variables ->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +###################################### -Before running Yardstick it is necessary to export OpenStack environment variables:: +Before running Yardstick it is necessary to export OpenStack environment +variables:: - source openrc + source openrc -Environment variables in the ``openrc`` file have to include at least: +Environment variables in the ``openrc`` file have to include at least:: -* ``OS_AUTH_URL`` -* ``OS_USERNAME`` -* ``OS_PASSWORD`` -* ``OS_TENANT_NAME`` -* ``EXTERNAL_NETWORK`` + OS_AUTH_URL + OS_USERNAME + OS_PASSWORD + OS_TENANT_NAME + EXTERNAL_NETWORK -A sample `openrc` file may look like this:: +A sample ``openrc`` file may look like this:: export OS_PASSWORD=console export OS_TENANT_NAME=admin @@ -175,17 +178,23 @@ A sample `openrc` file may look like this:: export OS_VOLUME_API_VERSION=2 export EXTERNAL_NETWORK=net04_ext -Manually create Yardstick falvor and guest images ->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Before executing Yardstick test cases, make sure that Yardstick flavor and guest image are available in OpenStack. Detailed steps about creating the Yardstick flavor and building the Yardstick guest image can be found below. +Manual creation of Yardstick flavor and guest images +#################################################### + +Before executing Yardstick test cases, make sure that Yardstick flavor and +guest image are available in OpenStack. Detailed steps about creating the +Yardstick flavor and building the Yardstick guest image can be found below. Most of the sample test cases in Yardstick are using an OpenStack flavor called -``yardstick-flavor`` which deviates from the OpenStack standard ``m1.tiny`` flavor by the disk size - instead of 1GB it has 3GB. Other parameters are the same as in ``m1.tiny``. +``yardstick-flavor`` which deviates from the OpenStack standard ``m1.tiny`` +flavor by the disk size; instead of 1GB it has 3GB. Other parameters are the +same as in ``m1.tiny``. Create ``yardstick-flavor``:: - nova flavor-create yardstick-flavor 100 512 3 1 + openstack flavor create --disk 3 --vcpus 1 --ram 512 --swap 100 \ + yardstick-flavor Most of the sample test cases in Yardstick are using a guest image called ``yardstick-image`` which deviates from an Ubuntu Cloud Server image @@ -196,126 +205,231 @@ Yardstick has a tool for building this custom image. It is necessary to have Also you may need install several additional packages to use this tool, by follwing the commands below:: - sudo apt-get update && sudo apt-get install -y qemu-utils kpartx - -This image can be built using the following command in the directory where Yardstick is installed:: + sudo -EH apt-get update && sudo -EH apt-get install -y qemu-utils kpartx - export YARD_IMG_ARCH='amd64' - sudo echo "Defaults env_keep += \'YARD_IMG_ARCH\'" >> /etc/sudoers - sudo tools/yardstick-img-modify tools/ubuntu-server-cloudimg-modify.sh +This image can be built using the following command in the directory where +Yardstick is installed:: -**Warning:** Before building the guest image inside the Yardstick container, make sure the container is granted with privilege. The script will create files by default in ``/tmp/workspace/yardstick`` and the files will be owned by root! + export YARD_IMG_ARCH='amd64' + echo "Defaults env_keep += \'YARD_IMG_ARCH\'" | sudo tee --append \ + /etc/sudoers > /dev/null + sudo -EH tools/yardstick-img-modify tools/ubuntu-server-cloudimg-modify.sh -The created image can be added to OpenStack using the ``glance image-create`` or via the OpenStack Dashboard. Example command is:: +.. warning:: Before building the guest image inside the Yardstick container, +make sure the container is granted with privilege. The script will create files +by default in ``/tmp/workspace/yardstick`` and the files will be owned by root. - glance --os-image-api-version 1 image-create \ - --name yardstick-image --is-public true \ - --disk-format qcow2 --container-format bare \ - --file /tmp/workspace/yardstick/yardstick-image.img +The created image can be added to OpenStack using the OpenStack client or via +the OpenStack Dashboard:: -.. _`Cirros 0.3.5`: http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img -.. _`Ubuntu 16.04`: https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img + openstack image create --disk-format qcow2 --container-format bare \ + --public --file /tmp/workspace/yardstick/yardstick-image.img \ + yardstick-image -Some Yardstick test cases use a `Cirros 0.3.5`_ image and/or a `Ubuntu 16.04`_ image. Add Cirros and Ubuntu images to OpenStack:: - openstack image create \ - --disk-format qcow2 \ - --container-format bare \ - --file $cirros_image_file \ - cirros-0.3.5 +Some Yardstick test cases use a `Cirros 0.3.5`_ image and/or a `Ubuntu 16.04`_ +image. Add Cirros and Ubuntu images to OpenStack:: - openstack image create \ - --disk-format qcow2 \ - --container-format bare \ - --file $ubuntu_image_file \ - Ubuntu-16.04 + openstack image create --disk-format qcow2 --container-format bare \ + --public --file $cirros_image_file cirros-0.3.5 + openstack image create --disk-format qcow2 --container-format bare \ + --file $ubuntu_image_file Ubuntu-16.04 -The third way -################ +Automatic initialization of OpenStack (third way) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Similar to the second way, the first step is also to `Export OpenStack environment variables`_. Then the following steps should be done. +Similar to the second way, the first step is also to +`Export OpenStack environment variables`_. Then the following steps should be +done. -Automatically create Yardstcik flavor and guest images ->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +Automatic creation of Yardstick flavor and guest images +####################################################### Yardstick has a script for automatically creating Yardstick flavor and building -Yardstick guest images. This script is mainly used for CI and can be also used in the local environment:: +Yardstick guest images. This script is mainly used for CI and can be also used +in the local environment:: - source $YARDSTICK_REPO_DIR/tests/ci/load_images.sh + source $YARDSTICK_REPO_DIR/tests/ci/load_images.sh +The Yardstick container GUI +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In Euphrates release, Yardstick implemented a GUI for Yardstick Docker +container. After booting up Yardstick container, you can visit the GUI at +``<container_host_ip>:8888/gui/index.html``. + +For usage of Yardstick GUI, please watch our demo video at +`Yardstick GUI demo`_. + +.. note:: The Yardstick GUI is still in development, the GUI layout and +features may change. + Delete the Yardstick container -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you want to uninstall Yardstick, just delete the Yardstick container:: - docker stop yardstick && docker rm yardstick + sudo docker stop yardstick && docker rm yardstick + -Install Yardstick directly in Ubuntu ---------------------------------------- +Install Yardstick directly in Ubuntu (second option) +---------------------------------------------------- .. _install-framework: -Alternatively you can install Yardstick framework directly in Ubuntu or in an Ubuntu Docker image. No matter which way you choose to install Yardstick, the following installation steps are identical. +Alternatively you can install Yardstick framework directly in Ubuntu or in an +Ubuntu Docker image. No matter which way you choose to install Yardstick, the +following installation steps are identical. If you choose to use the Ubuntu Docker image, you can pull the Ubuntu Docker image from Docker hub:: - docker pull ubuntu:16.04 + sudo -EH docker pull ubuntu:16.04 Install Yardstick -^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^ Prerequisite preparation:: - apt-get update && apt-get install -y git python-setuptools python-pip - easy_install -U setuptools==30.0.0 - pip install appdirs==1.4.0 - pip install virtualenv + sudo -EH apt-get update && sudo -EH apt-get install -y \ + git python-setuptools python-pip + sudo -EH easy_install -U setuptools==30.0.0 + sudo -EH pip install appdirs==1.4.0 + sudo -EH pip install virtualenv Create a virtual environment:: - virtualenv ~/yardstick_venv - export YARDSTICK_VENV=~/yardstick_venv - source ~/yardstick_venv/bin/activate + virtualenv ~/yardstick_venv + export YARDSTICK_VENV=~/yardstick_venv + source ~/yardstick_venv/bin/activate Download the source code and install Yardstick from it:: - git clone https://gerrit.opnfv.org/gerrit/yardstick - export YARDSTICK_REPO_DIR=~/yardstick - cd yardstick - ./install.sh + git clone https://gerrit.opnfv.org/gerrit/yardstick + export YARDSTICK_REPO_DIR=~/yardstick + cd ~/yardstick + sudo -EH ./install.sh Configure the Yardstick environment (**Todo**) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -For installing Yardstick directly in Ubuntu, the ``yardstick env`` command is not available. You need to prepare OpenStack environment variables and create Yardstick flavor and guest images manually. +For installing Yardstick directly in Ubuntu, the ``yardstick env`` command is +not available. You need to prepare OpenStack environment variables and create +Yardstick flavor and guest images manually. Uninstall Yardstick -^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^ + +For uninstalling Yardstick, just delete the virtual environment:: + + rm -rf ~/yardstick_venv + + +Install Yardstick directly in OpenSUSE +-------------------------------------- + +.. _install-framework: + +You can install Yardstick framework directly in OpenSUSE. + + +Install Yardstick +^^^^^^^^^^^^^^^^^ + +Prerequisite preparation:: + + sudo -EH zypper -n install -y gcc \ + wget \ + git \ + sshpass \ + qemu-tools \ + kpartx \ + libffi-devel \ + libopenssl-devel \ + python \ + python-devel \ + python-virtualenv \ + libxml2-devel \ + libxslt-devel \ + python-setuptools-git + +Create a virtual environment:: + + virtualenv ~/yardstick_venv + export YARDSTICK_VENV=~/yardstick_venv + source ~/yardstick_venv/bin/activate + sudo -EH easy_install -U setuptools + +Download the source code and install Yardstick from it:: + + git clone https://gerrit.opnfv.org/gerrit/yardstick + export YARDSTICK_REPO_DIR=~/yardstick + cd yardstick + sudo -EH python setup.py install + sudo -EH pip install -r requirements.txt + +Install missing python modules:: + + sudo -EH pip install pyyaml \ + oslo_utils \ + oslo_serialization \ + oslo_config \ + paramiko \ + python.heatclient \ + python.novaclient \ + python.glanceclient \ + python.neutronclient \ + scp \ + jinja2 + + +Configure the Yardstick environment +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Source the OpenStack environment variables:: + + source DEVSTACK_DIRECTORY/openrc + +Export the Openstack external network. The default installation of Devstack +names the external network public:: + + export EXTERNAL_NETWORK=public + export OS_USERNAME=demo + +Change the API version used by Yardstick to v2.0 (the devstack openrc sets it +to v3):: + + export OS_AUTH_URL=http://PUBLIC_IP_ADDRESS:5000/v2.0 + + +Uninstall Yardstick +^^^^^^^^^^^^^^^^^^^ For unistalling Yardstick, just delete the virtual environment:: - rm -rf ~/yardstick_venv + rm -rf ~/yardstick_venv Verify the installation ------------------------------ +----------------------- It is recommended to verify that Yardstick was installed successfully by executing some simple commands and test samples. Before executing Yardstick -test cases make sure ``yardstick-flavor`` and ``yardstick-image`` can be found in OpenStack and the ``openrc`` file is sourced. Below is an example -invocation of Yardstick ``help`` command and ``ping.py`` test sample:: +test cases make sure ``yardstick-flavor`` and ``yardstick-image`` can be found +in OpenStack and the ``openrc`` file is sourced. Below is an example invocation +of Yardstick ``help`` command and ``ping.py`` test sample:: - yardstick -h - yardstick task start samples/ping.yaml + yardstick -h + yardstick task start samples/ping.yaml -**NOTE:** The above commands could be run in both the Yardstick container and the Ubuntu directly. +.. note:: The above commands could be run in both the Yardstick container and +the Ubuntu directly. Each testing tool supported by Yardstick has a sample configuration file. These configuration files can be found in the ``samples`` directory. @@ -324,166 +438,145 @@ Default location for the output is ``/tmp/yardstick.out``. Deploy InfluxDB and Grafana using Docker -------------------------------------------- +---------------------------------------- -Without InfluxDB, Yardstick stores results for runnning test case in the file -``/tmp/yardstick.out``. However, it's unconvenient to retrieve and display +Without InfluxDB, Yardstick stores results for running test case in the file +``/tmp/yardstick.out``. However, it's inconvenient to retrieve and display test results. So we will show how to use InfluxDB to store data and use Grafana to display data in the following sections. -Automatically deploy InfluxDB and Grafana containers (**recommended**) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Automatic deployment of InfluxDB and Grafana containers (**recommended**) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Firstly, enter the Yardstick container:: - docker exec -it yardstick /bin/bash + sudo -EH docker exec -it yardstick /bin/bash Secondly, create InfluxDB container and configure with the following command:: - yardstick env influxdb + yardstick env influxdb Thirdly, create and configure Grafana container:: - yardstick env grafana + yardstick env grafana -Then you can run a test case and visit http://host_ip:3000 (``admin``/``admin``) to see the results. +Then you can run a test case and visit http://host_ip:3000 +(``admin``/``admin``) to see the results. -**NOTE:** Executing ``yardstick env`` command to deploy InfluxDB and Grafana requires Jumphost's docker API version => 1.24. Run the following command to check the docker API version on the Jumphost:: +.. note:: Executing ``yardstick env`` command to deploy InfluxDB and Grafana +requires Jumphost's docker API version => 1.24. Run the following command to +check the docker API version on the Jumphost:: - docker version + docker version -Manually deploy InfluxDB and Grafana containers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -You could also deploy influxDB and Grafana containers manually on the Jumphost. -The following sections show how to do. - -.. pull docker images - -Pull docker images -#################### +Manual deployment of InfluxDB and Grafana containers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: +You can also deploy influxDB and Grafana containers manually on the Jumphost. +The following sections show how to do. - docker pull tutum/influxdb - docker pull grafana/grafana +Pull docker images:: -Run and configure influxDB -############################### + sudo -EH docker pull tutum/influxdb + sudo -EH docker pull grafana/grafana Run influxDB:: - docker run -d --name influxdb \ - -p 8083:8083 -p 8086:8086 --expose 8090 --expose 8099 \ - tutum/influxdb - docker exec -it influxdb bash + sudo -EH docker run -d --name influxdb \ + -p 8083:8083 -p 8086:8086 --expose 8090 --expose 8099 \ + tutum/influxdb + docker exec -it influxdb bash Configure influxDB:: - influx - >CREATE USER root WITH PASSWORD 'root' WITH ALL PRIVILEGES - >CREATE DATABASE yardstick; - >use yardstick; - >show MEASUREMENTS; - -Run and configure Grafana -############################### + influx + >CREATE USER root WITH PASSWORD 'root' WITH ALL PRIVILEGES + >CREATE DATABASE yardstick; + >use yardstick; + >show MEASUREMENTS; Run Grafana:: - docker run -d --name grafana -p 3000:3000 grafana/grafana + sudo -EH docker run -d --name grafana -p 3000:3000 grafana/grafana -Log on http://{YOUR_IP_HERE}:3000 using ``admin``/``admin`` and configure database resource to be ``{YOUR_IP_HERE}:8086``. +Log on http://{YOUR_IP_HERE}:3000 using ``admin``/``admin`` and configure +database resource to be ``{YOUR_IP_HERE}:8086``. .. image:: images/Grafana_config.png :width: 800px - :alt: Grafana data source configration + :alt: Grafana data source configuration -Configure ``yardstick.conf`` -############################## +Configure ``yardstick.conf``:: -:: - - docker exec -it yardstick /bin/bash - cp etc/yardstick/yardstick.conf.sample /etc/yardstick/yardstick.conf - vi /etc/yardstick/yardstick.conf + sudo -EH docker exec -it yardstick /bin/bash + sudo cp etc/yardstick/yardstick.conf.sample /etc/yardstick/yardstick.conf + sudo vi /etc/yardstick/yardstick.conf Modify ``yardstick.conf``:: - [DEFAULT] - debug = True - dispatcher = influxdb + [DEFAULT] + debug = True + dispatcher = influxdb - [dispatcher_influxdb] - timeout = 5 - target = http://{YOUR_IP_HERE}:8086 - db_name = yardstick - username = root - password = root + [dispatcher_influxdb] + timeout = 5 + target = http://{YOUR_IP_HERE}:8086 + db_name = yardstick + username = root + password = root Now you can run Yardstick test cases and store the results in influxDB. Deploy InfluxDB and Grafana directly in Ubuntu (**Todo**) ------------------------------------------------------------ +--------------------------------------------------------- Yardstick common CLI -------------------- -list test cases ->>>>>>>>>>>>>>> -**yardstick testcase list** - -This command line would list all test cases in yardstick. -It would show like below:: - - +--------------------------------------------------------------------------------------- - | Testcase Name | Description - +--------------------------------------------------------------------------------------- - | opnfv_yardstick_tc001 | Measure network throughput using pktgen - | opnfv_yardstick_tc002 | measure network latency using ping - | opnfv_yardstick_tc005 | Measure Storage IOPS, throughput and latency using fio. - | opnfv_yardstick_tc006 | Measure volume storage IOPS, throughput and latency using fio. - | opnfv_yardstick_tc008 | Measure network throughput and packet loss using Pktgen - | opnfv_yardstick_tc009 | Measure network throughput and packet loss using pktgen - | opnfv_yardstick_tc010 | measure memory read latency using lmbench. - | opnfv_yardstick_tc011 | Measure packet delay variation (jitter) using iperf3. - | opnfv_yardstick_tc012 | Measure memory read and write bandwidth using lmbench. - | opnfv_yardstick_tc014 | Measure Processing speed using unixbench. - | opnfv_yardstick_tc019 | Sample test case for the HA of controller node service. - ... - +--------------------------------------------------------------------------------------- -show a test case config file ->>>>>>>>>>>>>>>>>>>>>>>>>>>> -Take opnfv_yardstick_tc002 for an example. This test case measure network latency. -You just need to type in **yardstick testcase show opnfv_yardstick_tc002**, and the console -would show the config yaml of this test case:: - ############################################################################## - # Copyright (c) 2017 kristian.hunt@gmail.com and others. - # - # All rights reserved. This program and the accompanying materials - # are made available under the terms of the Apache License, Version 2.0 - # which accompanies this distribution, and is available at - # http://www.apache.org/licenses/LICENSE-2.0 - ############################################################################## - --- - - schema: "yardstick:task:0.1" - description: > +List test cases +^^^^^^^^^^^^^^^ + +``yardstick testcase list``: This command line would list all test cases in +Yardstick. It would show like below:: + + +--------------------------------------------------------------------------------------- + | Testcase Name | Description + +--------------------------------------------------------------------------------------- + | opnfv_yardstick_tc001 | Measure network throughput using pktgen + | opnfv_yardstick_tc002 | measure network latency using ping + | opnfv_yardstick_tc005 | Measure Storage IOPS, throughput and latency using fio. + ... + +--------------------------------------------------------------------------------------- + + +Show a test case config file +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Take opnfv_yardstick_tc002 for an example. This test case measure network +latency. You just need to type in ``yardstick testcase show +opnfv_yardstick_tc002``, and the console would show the config yaml of this +test case:: + + --- + + schema: "yardstick:task:0.1" + description: > Yardstick TC002 config file; measure network latency using ping; - {% set image = image or "cirros-0.3.5" %} + {% set image = image or "cirros-0.3.5" %} - {% set provider = provider or none %} - {% set physical_network = physical_network or 'physnet1' %} - {% set segmentation_id = segmentation_id or none %} - {% set packetsize = packetsize or 100 %} + {% set provider = provider or none %} + {% set physical_network = physical_network or 'physnet1' %} + {% set segmentation_id = segmentation_id or none %} + {% set packetsize = packetsize or 100 %} - scenarios: - {% for i in range(2) %} - - + scenarios: + {% for i in range(2) %} + - type: Ping options: packetsize: {{packetsize}} @@ -498,9 +591,9 @@ would show the config yaml of this test case:: sla: max_rtt: 10 action: monitor - {% endfor %} + {% endfor %} - context: + context: name: demo image: {{image}} flavor: yardstick-flavor @@ -528,39 +621,41 @@ would show the config yaml of this test case:: {% endif %} {% endif %} -start a task to run yardstick test case ->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -If you want run a test case, then you need to use **yardstick task start <test_case_path>** -this command support some parameters as below: - -+---------------------+--------------------------------------------------+ -| Parameters | Detail | -+=====================+==================================================+ -| -d | show debug log of yardstick running | -| | | -+---------------------+--------------------------------------------------+ -| --task-args | If you want to customize test case parameters, | -| | use "--task-args" to pass the value. The format | -| | is a json string with parameter key-value pair. | -| | | -+---------------------+--------------------------------------------------+ -| --task-args-file | If you want to use yardstick | -| | env prepare command(or | -| | related API) to load the | -+---------------------+--------------------------------------------------+ -| --parse-only | | -| | | -| | | -+---------------------+--------------------------------------------------+ -| --output-file \ | Specify where to output the log. if not pass, | -| OUTPUT_FILE_PATH | the default value is | -| | "/tmp/yardstick/yardstick.log" | -| | | -+---------------------+--------------------------------------------------+ -| --suite \ | run a test suite, TEST_SUITE_PATH speciy where | -| TEST_SUITE_PATH | the test suite locates | -| | | -+---------------------+--------------------------------------------------+ + +Start a task to run yardstick test case +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you want run a test case, then you need to use ``yardstick task start +<test_case_path>`` this command support some parameters as below:: + + +---------------------+--------------------------------------------------+ + | Parameters | Detail | + +=====================+==================================================+ + | -d | show debug log of yardstick running | + | | | + +---------------------+--------------------------------------------------+ + | --task-args | If you want to customize test case parameters, | + | | use "--task-args" to pass the value. The format | + | | is a json string with parameter key-value pair. | + | | | + +---------------------+--------------------------------------------------+ + | --task-args-file | If you want to use yardstick | + | | env prepare command(or | + | | related API) to load the | + +---------------------+--------------------------------------------------+ + | --parse-only | | + | | | + | | | + +---------------------+--------------------------------------------------+ + | --output-file \ | Specify where to output the log. if not pass, | + | OUTPUT_FILE_PATH | the default value is | + | | "/tmp/yardstick/yardstick.log" | + | | | + +---------------------+--------------------------------------------------+ + | --suite \ | run a test suite, TEST_SUITE_PATH specify where | + | TEST_SUITE_PATH | the test suite locates | + | | | + +---------------------+--------------------------------------------------+ Run Yardstick in a local environment @@ -568,7 +663,7 @@ Run Yardstick in a local environment We also have a guide about how to run Yardstick in a local environment. This work is contributed by Tapio Tallgren. -You can find this guide at `here <https://wiki.opnfv.org/display/yardstick/How+to+run+Yardstick+in+a+local+environment>`_. +You can find this guide at `How to run Yardstick in a local environment`_. Create a test suite for Yardstick @@ -578,19 +673,20 @@ A test suite in yardstick is a yaml file which include one or more test cases. Yardstick is able to support running test suite task, so you can customize your own test suite and run it in one task. -``tests/opnfv/test_suites`` is the folder where Yardstick puts CI test suite. A typical test suite is like below (the ``fuel_test_suite.yaml`` example):: +``tests/opnfv/test_suites`` is the folder where Yardstick puts CI test suite. +A typical test suite is like below (the ``fuel_test_suite.yaml`` example):: - --- - # Fuel integration test task suite + --- + # Fuel integration test task suite - schema: "yardstick:suite:0.1" + schema: "yardstick:suite:0.1" - name: "fuel_test_suite" - test_cases_dir: "samples/" - test_cases: - - + name: "fuel_test_suite" + test_cases_dir: "samples/" + test_cases: + - file_name: ping.yaml - - + - file_name: iperf3.yaml As you can see, there are two test cases in the ``fuel_test_suite.yaml``. The @@ -602,18 +698,18 @@ Yardstick test suite also supports constraints and task args for each test case. Here is another sample (the ``os-nosdn-nofeature-ha.yaml`` example) to show this, which is digested from one big test suite:: - --- + --- - schema: "yardstick:suite:0.1" + schema: "yardstick:suite:0.1" - name: "os-nosdn-nofeature-ha" - test_cases_dir: "tests/opnfv/test_cases/" - test_cases: - - + name: "os-nosdn-nofeature-ha" + test_cases_dir: "tests/opnfv/test_cases/" + test_cases: + - file_name: opnfv_yardstick_tc002.yaml - - + - file_name: opnfv_yardstick_tc005.yaml - - + - file_name: opnfv_yardstick_tc043.yaml constraint: installer: compass @@ -631,6 +727,77 @@ All in all, to create a test suite in Yardstick, you just need to create a yaml file and add test cases, constraint or task arguments if necessary. -Proxy Support (**Todo**) ---------------------------- +Proxy Support +------------- + +To configure the Jumphost to access Internet through a proxy its necessary to +export several variables to the environment, contained in the following +script:: + #!/bin/sh + _proxy=<proxy_address> + _proxyport=<proxy_port> + _ip=$(hostname -I | awk '{print $1}') + + export ftp_proxy=http://$_proxy:$_proxyport + export FTP_PROXY=http://$_proxy:$_proxyport + export http_proxy=http://$_proxy:$_proxyport + export HTTP_PROXY=http://$_proxy:$_proxyport + export https_proxy=http://$_proxy:$_proxyport + export HTTPS_PROXY=http://$_proxy:$_proxyport + export no_proxy=127.0.0.1,localhost,$_ip,$(hostname),<.localdomain> + export NO_PROXY=127.0.0.1,localhost,$_ip,$(hostname),<.localdomain> + +To enable Internet access from a container using ``docker``, depends on the OS +version. On Ubuntu 14.04 LTS, which uses SysVinit, ``/etc/default/docker`` must +be modified:: + + ....... + # If you need Docker to use an HTTP proxy, it can also be specified here. + export http_proxy="http://<proxy_address>:<proxy_port>/" + export https_proxy="https://<proxy_address>:<proxy_port>/" + +Then its necessary to restart the ``docker`` service:: + + sudo -EH service docker restart + +In Ubuntu 16.04 LTS, which uses Systemd, its necessary to create a drop-in +directory:: + + sudo mkdir /etc/systemd/system/docker.service.d + +Then, the proxy configuration will be stored in the following file:: + + # cat /etc/systemd/system/docker.service.d/http-proxy.conf + [Service] + Environment="HTTP_PROXY=https://<proxy_address>:<proxy_port>/" + Environment="HTTPS_PROXY=https://<proxy_address>:<proxy_port>/" + Environment="NO_PROXY=localhost,127.0.0.1,<localaddress>,<.localdomain>" + +The changes need to be flushed and the ``docker`` service restarted:: + + sudo systemctl daemon-reload + sudo systemctl restart docker + +Any container is already created won't contain these modifications. If needed, +stop and delete the container:: + + sudo docker stop yardstick + sudo docker rm yardstick + +.. warning:: Be careful, the above ``rm`` command will delete the container +completely. Everything on this container will be lost. + +Then follow the previous instructions `Prepare the Yardstick container`_ to +rebuild the Yardstick container. + + +References +---------- + +.. _`User Guide & Configuration Guide`: http://docs.opnfv.org/en/latest/release/userguide.introduction.html +.. _dockerhub: https://hub.docker.com/r/opnfv/yardstick/ +.. _`Cirros 0.3.5`: http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img +.. _`Ubuntu 16.04`: https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img +.. _`Yardstick GUI demo`: https://www.youtube.com/watch?v=M3qbJDp6QBk +.. _`How to run Yardstick in a local environment`: https://wiki.opnfv.org/display/yardstick/How+to+run+Yardstick+in+a+local+environment diff --git a/docs/testing/user/userguide/08-api.rst b/docs/testing/user/userguide/08-api.rst index 1d9ea6d64..ff6e62228 100644 --- a/docs/testing/user/userguide/08-api.rst +++ b/docs/testing/user/userguide/08-api.rst @@ -10,7 +10,7 @@ Yardstick Restful API Abstract -------- -Yardstick support restful API in danube. +Yardstick support restful API since Danube. Available API @@ -19,19 +19,19 @@ Available API /yardstick/env/action ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Description: This API is used to do some work related to environment. For now, we support: +Description: This API is used to prepare Yardstick test environment. For Euphrates, it supports: -1. Prepare yardstick environment(Including fetch openrc file, get external network and load images) -2. Start a InfluxDB docker container and config yardstick output to InfluxDB. -3. Start a Grafana docker container and config with the InfluxDB. +1. Prepare yardstick test environment, including set external network environment variable, load Yardstick VM images and create flavors; +2. Start an InfluxDB Docker container and config Yardstick output to InfluxDB; +3. Start a Grafana Docker container and config it with the InfluxDB. -Which API to call will depend on the Parameters. +Which API to call will depend on the parameters. Method: POST -Prepare Yardstick Environment +Prepare Yardstick test environment Example:: { @@ -41,7 +41,7 @@ Example:: This is an asynchronous API. You need to call /yardstick/asynctask API to get the task result. -Start and Config InfluxDB docker container +Start and config an InfluxDB docker container Example:: { @@ -51,7 +51,7 @@ Example:: This is an asynchronous API. You need to call /yardstick/asynctask API to get the task result. -Start and Config Grafana docker container +Start and config a Grafana docker container Example:: { @@ -64,13 +64,13 @@ This is an asynchronous API. You need to call /yardstick/asynctask API to get th /yardstick/asynctask ^^^^^^^^^^^^^^^^^^^^ -Description: This API is used to get the status of asynchronous task +Description: This API is used to get the status of asynchronous tasks Method: GET -Get the status of asynchronous task +Get the status of asynchronous tasks Example:: http://localhost:8888/yardstick/asynctask?task_id=3f3f5e03-972a-4847-a5f8-154f1b31db8c @@ -81,13 +81,13 @@ The returned status will be 0(running), 1(finished) and 2(failed). /yardstick/testcases ^^^^^^^^^^^^^^^^^^^^ -Description: This API is used to list all release test cases now in yardstick. +Description: This API is used to list all released Yardstick test cases. Method: GET -Get a list of release test cases +Get a list of released test cases Example:: http://localhost:8888/yardstick/testcases @@ -96,13 +96,13 @@ Example:: /yardstick/testcases/release/action ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Description: This API is used to run a yardstick release test case. +Description: This API is used to run a Yardstick released test case. Method: POST -Run a release test case +Run a released test case Example:: { @@ -119,7 +119,7 @@ This is an asynchronous API. You need to call /yardstick/results to get the resu /yardstick/testcases/samples/action ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Description: This API is used to run a yardstick sample test case. +Description: This API is used to run a Yardstick sample test case. Method: POST @@ -139,10 +139,25 @@ Example:: This is an asynchronous API. You need to call /yardstick/results to get the result. +/yardstick/testcases/<testcase_name>/docs +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Description: This API is used to the documentation of a certain released test case. + + +Method: GET + + +Get the documentation of a certain test case +Example:: + + http://localhost:8888/yardstick/taskcases/opnfv_yardstick_tc002/docs + + /yardstick/testsuites/action ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Description: This API is used to run a yardstick test suite. +Description: This API is used to run a Yardstick test suite. Method: POST @@ -162,11 +177,27 @@ Example:: This is an asynchronous API. You need to call /yardstick/results to get the result. +/yardstick/tasks/<task_id>/log + +Description: This API is used to get the real time log of test case execution. + + +Method: GET + + +Get real time of test case execution +Example:: + + http://localhost:8888/yardstick/tasks/14795be8-f144-4f54-81ce-43f4e3eab33f/log?index=0 + + /yardstick/results ^^^^^^^^^^^^^^^^^^ +Description: This API is used to get the test results of tasks. If you call /yardstick/testcases/samples/action API, it will return a task id. You can use the returned task id to get the results by using this API. + -Description: This API is used to get the test results of certain task. If you call /yardstick/testcases/samples/action API, it will return a task id. You can use the returned task id to get the results by using this API. +Method: GET Get test results of one task @@ -175,3 +206,457 @@ Example:: http://localhost:8888/yardstick/results?task_id=3f3f5e03-972a-4847-a5f8-154f1b31db8c This API will return a list of test case result + + +/api/v2/yardstick/openrcs/action + +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; +3. Get openrc file information; +4. Delete an openrc file. + +Which API to call will depend on the parameters. + + +METHOD: POST + + +Upload an openrc file for an OpenStack environment +Example:: + + { + 'action': 'upload_openrc', + 'args': { + 'file': file, + 'environment_id': environment_id + } + } + + +METHOD: POST + + +Update an openrc file +Example:: + + { + 'action': 'update_openrc', + 'args': { + 'openrc': { + "EXTERNAL_NETWORK": "ext-net", + "OS_AUTH_URL": "http://192.168.23.51:5000/v3", + "OS_IDENTITY_API_VERSION": "3", + "OS_IMAGE_API_VERSION": "2", + "OS_PASSWORD": "console", + "OS_PROJECT_DOMAIN_NAME": "default", + "OS_PROJECT_NAME": "admin", + "OS_TENANT_NAME": "admin", + "OS_USERNAME": "admin", + "OS_USER_DOMAIN_NAME": "default" + }, + 'environment_id': environment_id + } + } + + +METHOD: GET + +Get openrc file information +Example:: + + http://localhost:8888/api/v2/yardstick/openrcs/5g6g3e02-155a-4847-a5f8-154f1b31db8c + + +METHOD: DELETE + + +Delete openrc file +Example:: + + http://localhost:8888/api/v2/yardstick/openrcs/5g6g3e02-155a-4847-a5f8-154f1b31db8c + + +/api/v2/yardstick/pods/action + +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. + + +METHOD: POST + + +Upload a pod.yaml file +Example:: + + { + 'action': 'upload_pod_file', + 'args': { + 'file': file, + 'environment_id': environment_id + } + } + + +METHOD: GET + +Get pod file information +Example:: + + http://localhost:8888/api/v2/yardstick/pods/5g6g3e02-155a-4847-a5f8-154f1b31db8c + + +METHOD: DELETE + +Delete openrc file +Example:: + + http://localhost:8888/api/v2/yardstick/pods/5g6g3e02-155a-4847-a5f8-154f1b31db8c + + +/api/v2/yardstick/images/action + +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. + + +METHOD: POST + + +Load VM images +Example:: + + { + 'action': 'load_images' + } + + +METHOD: GET + +Get image information +Example:: + + http://localhost:8888/api/v2/yardstick/images/5g6g3e02-155a-4847-a5f8-154f1b31db8c + + +METHOD: DELETE + +Delete images +Example:: + + http://localhost:8888/api/v2/yardstick/images/5g6g3e02-155a-4847-a5f8-154f1b31db8c + + +/api/v2/yardstick/tasks/action + +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. + + +METHOD: POST + + +Create a Yardstick task +Example:: + + { + 'action': 'create_task', + 'args': { + 'name': 'task1', + 'project_id': project_id + } + } + + +METHOD: PUT + + +Run a task +Example:: + + { + 'action': 'run' + } + + +METHOD: PUT + + +Add a test case to a task +Example:: + + { + 'action': 'add_case', + 'args': { + 'case_name': 'opnfv_yardstick_tc002', + 'case_content': case_content + } + } + + +METHOD: PUT + + +Add a test suite to a task +Example:: + + { + 'action': 'add_suite', + 'args': { + 'suite_name': 'opnfv_smoke', + 'suite_content': suite_content + } + } + + +METHOD: GET + +Get a task's information +Example:: + + http://localhost:8888/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 + + +/api/v2/yardstick/testcases/action + +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. + + +METHOD: POST + + +Upload a test case +Example:: + + { + 'action': 'upload_case', + 'args': { + 'file': file + } + } + + +METHOD: GET + + +Get all released test cases' information +Example:: + + http://localhost:8888/api/v2/yardstick/testcases + + +METHOD: GET + + +Get a certain released test case's information +Example:: + + http://localhost:8888/api/v2/yardstick/testcases/opnfv_yardstick_tc002 + + +METHOD: DELETE + + +Delete a certain test case +Example:: + http://localhost:8888/api/v2/yardstick/testcases/opnfv_yardstick_tc002 + + +/api/v2/yardstick/testsuites/action + +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. + +Which API to call will depend on the parameters. + + +METHOD: POST + + +Create a test suite +Example:: + + { + 'action': 'create_sutie', + 'args': { + 'name': <suite_name>, + 'testcases': [ + 'opnfv_yardstick_tc002' + ] + } + } + + +METHOD: GET + + +Get a certain test suite's information +Example:: + + http://localhost:8888/api/v2/yardstick/testsuites/<suite_name> + + +METHOD: GET + + +Get all test suite +Example:: + + http://localhost:8888/api/v2/yardstick/testsuites + + +METHOD: DELETE + + +Delete a certain test suite +Example:: + + http://localhost:8888/api/v2/yardstick/testsuites/<suite_name> + + +/api/v2/yardstick/projects/action + +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. + +Which API to call will depend on the parameters. + + +METHOD: POST + + +Create a Yardstick project +Example:: + + { + 'action': 'create_project', + 'args': { + 'name': 'project1' + } + } + + +METHOD: GET + + +Get a certain project's information +Example:: + + http://localhost:8888/api/v2/yardstick/projects/<project_id> + + +METHOD: GET + + +Get all projects' information +Example:: + + http://localhost:8888/api/v2/yardstick/projects + + +METHOD: DELETE + + +Delete a certain project +Example:: + + http://localhost:8888/api/v2/yardstick/projects/<project_id> + + +/api/v2/yardstick/containers/action + +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. + + +METHOD: POST + + +Create a Grafana Docker container +Example:: + + { + 'action': 'create_grafana', + 'args': { + 'environment_id': <environment_id> + } + } + + +METHOD: POST + + +Create an InfluxDB Docker container +Example:: + + { + 'action': 'create_influxdb', + 'args': { + 'environment_id': <environment_id> + } + } + + +METHOD: GET + + +Get a certain container's information +Example:: + + http://localhost:8888/api/v2/yardstick/containers/<container_id> + + +METHOD: DELETE + + +Delete a certain container +Example:: + + http://localhost:8888/api/v2/yardstick/containers/<container_id> diff --git a/docs/testing/user/userguide/13-nsb-overview.rst b/docs/testing/user/userguide/11-nsb-overview.rst index 63442bff0..8ce90f65d 100644 --- a/docs/testing/user/userguide/13-nsb-overview.rst +++ b/docs/testing/user/userguide/11-nsb-overview.rst @@ -3,12 +3,11 @@ .. http://creativecommons.org/licenses/by/4.0 .. (c) OPNFV, 2016-2017 Intel Corporation. -===================================== Network Services Benchmarking (NSB) -===================================== +=================================== Abstract -======== +-------- .. _Yardstick: https://wiki.opnfv.org/yardstick @@ -16,9 +15,9 @@ This chapter provides an overview of the NSB, a contribution to OPNFV Yardstick_ from Intel. Overview -======== +-------- -GOAL: Extend Yardstick to perform real world VNFs and NFVi Characterization and +The goal of NSB is to Extend Yardstick to perform real world VNFs and NFVi Characterization and benchmarking with repeatable and deterministic methods. The Network Service Benchmarking (NSB) extends the yardstick framework to do @@ -31,8 +30,7 @@ according to user defined profiles. NSB extension includes: - - Generic data models of Network Services, based on ETSI spec (ETSI GS NFV-TST 001) - .. _ETSI GS NFV-TST 001: http://www.etsi.org/deliver/etsi_gs/NFV-TST/001_099/001/01.01.01_60/gs_nfv-tst001v010101p.pdf + - Generic data models of Network Services, based on ETSI spec `ETSI GS NFV-TST 001 <http://www.etsi.org/deliver/etsi_gs/NFV-TST/001_099/001/01.01.01_60/gs_nfv-tst001v010101p.pdf>`_ - New Standalone context for VNF testing like SRIOV, OVS, OVS-DPDK etc @@ -72,7 +70,8 @@ NSB extension includes: - VNF KPIs, e.g., packet_in, packet_drop, packet_fwd etc Architecture -============ +------------ + The Network Service (NS) defines a set of Virtual Network Functions (VNF) connected together using NFV infrastructure. @@ -113,60 +112,60 @@ Network Service framework performs the necessary test steps. It may involve - Read the KPI's provided by particular VNF Components of Network Service ------------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -* *Models for Network Service benchmarking*: The Network Service benchmarking - requires the proper modelling approach. The NSB provides models using Python - files and defining of NSDs and VNFDs. + * *Models for Network Service benchmarking*: The Network Service benchmarking + requires the proper modelling approach. The NSB provides models using Python + files and defining of NSDs and VNFDs. -The benchmark control application being a part of OPNFV yardstick can call -that python models to instantiate and configure the VNFs. Depending on -infrastructure type (bare-metal or fully virtualized) that calls could be -made directly or using MANO system. + The benchmark control application being a part of OPNFV yardstick can call + that python models to instantiate and configure the VNFs. Depending on + infrastructure type (bare-metal or fully virtualized) that calls could be + made directly or using MANO system. -* *Traffic generators in NSB*: Any benchmark application requires a set of - traffic generator and traffic profiles defining the method in which traffic - is generated. + * *Traffic generators in NSB*: Any benchmark application requires a set of + traffic generator and traffic profiles defining the method in which traffic + is generated. -The Network Service benchmarking model extends the Network Service -definition with a set of Traffic Generators (TG) that are treated -same way as other VNFs being a part of benchmarked network service. -Same as other VNFs the traffic generator are instantiated and terminated. + The Network Service benchmarking model extends the Network Service + definition with a set of Traffic Generators (TG) that are treated + same way as other VNFs being a part of benchmarked network service. + Same as other VNFs the traffic generator are instantiated and terminated. -Every traffic generator has own configuration defined as a traffic profile and -a set of KPIs supported. The python models for TG is extended by specific calls -to listen and generate traffic. + Every traffic generator has own configuration defined as a traffic profile and + a set of KPIs supported. The python models for TG is extended by specific calls + to listen and generate traffic. -* *The stateless TREX traffic generator*: The main traffic generator used as - Network Service stimulus is open source TREX tool. + * *The stateless TREX traffic generator*: The main traffic generator used as + Network Service stimulus is open source TREX tool. -The TREX tool can generate any kind of stateless traffic. + The TREX tool can generate any kind of stateless traffic. -.. code-block:: console + .. code-block:: console - +--------+ +-------+ +--------+ - | | | | | | - | Trex | ---> | VNF | ---> | Trex | - | | | | | | - +--------+ +-------+ +--------+ + +--------+ +-------+ +--------+ + | | | | | | + | Trex | ---> | VNF | ---> | Trex | + | | | | | | + +--------+ +-------+ +--------+ -Supported testcases scenarios: + Supported testcases scenarios: - - Correlated UDP traffic using TREX traffic generator and replay VNF. + - Correlated UDP traffic using TREX traffic generator and replay VNF. - - using different IMIX configuration like pure voice, pure video traffic etc + - using different IMIX configuration like pure voice, pure video traffic etc - - using different number IP flows like 1 flow, 1K, 16K, 64K, 256K, 1M flows + - using different number IP flows like 1 flow, 1K, 16K, 64K, 256K, 1M flows - - Using different number of rules configured like 1 rule, 1K, 10K rules + - Using different number of rules configured like 1 rule, 1K, 10K rules -For UDP correlated traffic following Key Performance Indicators are collected -for every combination of test case parameters: + For UDP correlated traffic following Key Performance Indicators are collected + for every combination of test case parameters: - - RFC2544 throughput for various loss rate defined (1% is a default) + - RFC2544 throughput for various loss rate defined (1% is a default) Graphical Overview -================== +------------------ NSB Testing with yardstick framework facilitate performance testing of various VNFs provided. @@ -193,13 +192,12 @@ VNFs provided. Figure 1: Network Service - 2 server configuration VNFs supported for chracterization: ----------------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1. CGNAPT - Carrier Grade Network Address and port Translation 2. vFW - Virtual Firewall 3. vACL - Access Control List -4. vPE - Provider Edge Router 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, - QinQ encap/decap IPv4/IPv6, ARP, QoS, Routing, Unmpls, Policing, ACL + - 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 diff --git a/docs/testing/user/userguide/12-nsb_installation.rst b/docs/testing/user/userguide/12-nsb_installation.rst new file mode 100644 index 000000000..a584ca231 --- /dev/null +++ b/docs/testing/user/userguide/12-nsb_installation.rst @@ -0,0 +1,889 @@ +.. 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. + +Yardstick - NSB Testing -Installation +===================================== + +Abstract +-------- + +The Network Service Benchmarking (NSB) extends the yardstick framework to do +VNF characterization and benchmarking in three different execution +environments viz., bare metal i.e. native Linux environment, standalone virtual +environment and managed virtualized environment (e.g. Open stack etc.). +It also brings in the capability to interact with external traffic generators +both hardware & software based for triggering and validating the traffic +according to user defined profiles. + +The steps needed to run Yardstick with NSB testing are: + +* Install Yardstick (NSB Testing). +* Setup/Reference pod.yaml describing Test topology +* Create/Reference the test configuration yaml file. +* Run the test case. + + +Prerequisites +------------- + +Refer chapter Yardstick Installation for more information on yardstick +prerequisites + +Several prerequisites are needed for Yardstick(VNF testing): + + - Python Modules: pyzmq, pika. + + - flex + + - bison + + - build-essential + + - automake + + - libtool + + - librabbitmq-dev + + - rabbitmq-server + + - collectd + + - intel-cmt-cat + +Hardware & Software Ingredients +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +SUT requirements: + + + +-----------+--------------------+ + | Item | Description | + +-----------+--------------------+ + | Memory | Min 20GB | + +-----------+--------------------+ + | NICs | 2 x 10G | + +-----------+--------------------+ + | OS | Ubuntu 16.04.3 LTS | + +-----------+--------------------+ + | kernel | 4.4.0-34-generic | + +-----------+--------------------+ + | DPDK | 17.02 | + +-----------+--------------------+ + +Boot and BIOS settings: + + + +------------------+---------------------------------------------------+ + | Boot settings | default_hugepagesz=1G hugepagesz=1G hugepages=16 | + | | hugepagesz=2M hugepages=2048 isolcpus=1-11,22-33 | + | | nohz_full=1-11,22-33 rcu_nocbs=1-11,22-33 | + | | iommu=on iommu=pt intel_iommu=on | + | | Note: nohz_full and rcu_nocbs is to disable Linux | + | | kernel interrupts | + +------------------+---------------------------------------------------+ + |BIOS | CPU Power and Performance Policy <Performance> | + | | CPU C-state Disabled | + | | CPU P-state Disabled | + | | Enhanced Intel® Speedstep® Tech Disabled | + | | Hyper-Threading Technology (If supported) Enabled | + | | Virtualization Techology Enabled | + | | Intel(R) VT for Direct I/O Enabled | + | | Coherency Enabled | + | | Turbo Boost Disabled | + +------------------+---------------------------------------------------+ + + + +Install Yardstick (NSB Testing) +------------------------------- + +Download the source code and install Yardstick from it + +.. code-block:: console + + git clone https://gerrit.opnfv.org/gerrit/yardstick + + cd yardstick + + # Switch to latest stable branch + # git checkout <tag or stable branch> + git checkout stable/euphrates + +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' + +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 + + [yardstick-standalone] + yardstick-standalone-node ansible_host=192.168.1.2 + yardstick-standalone-node-2 ansible_host=192.168.1.3 + + # section below is only due backward compatibility. + # it will be removed later + [yardstick:children] + jumphost + + [all:vars] + ansible_user=root + ansible_pass=root + + +To execute an installation for a Bare-Metal or a Standalone context: + +.. code-block:: console + + ./nsb_setup.sh + + +To execute an installation for an OpenStack context: + +.. code-block:: console + + ./nsb_setup.sh <path to admin-openrc.sh> + +Above command setup docker with latest yardstick code. To execute + +.. code-block:: console + + docker exec -it yardstick bash + +It will also automatically download all the packages needed for NSB Testing setup. +Refer chapter :doc:`04-installation` for more on docker **Install Yardstick using Docker (recommended)** + +System Topology: +---------------- + +.. code-block:: console + + +----------+ +----------+ + | | | | + | | (0)----->(0) | | + | TG1 | | DUT | + | | | | + | | (1)<-----(1) | | + +----------+ +----------+ + trafficgen_1 vnf + + +Environment parameters and credentials +-------------------------------------- + +Config yardstick conf +^^^^^^^^^^^^^^^^^^^^^ + +If user did not run 'yardstick env influxdb' inside the container, which will generate +correct yardstick.conf, then create the config file manually (run inside the container): + + cp ./etc/yardstick/yardstick.conf.sample /etc/yardstick/yardstick.conf + vi /etc/yardstick/yardstick.conf + +Add trex_path, trex_client_lib and bin_path in 'nsb' section. + +:: + + [DEFAULT] + debug = True + dispatcher = file, influxdb + + [dispatcher_influxdb] + timeout = 5 + target = http://{YOUR_IP_HERE}:8086 + db_name = yardstick + username = root + password = root + + [nsb] + trex_path=/opt/nsb_bin/trex/scripts + bin_path=/opt/nsb_bin + trex_client_lib=/opt/nsb_bin/trex_client/stl + +Run Yardstick - Network Service Testcases +----------------------------------------- + + +NS testing - using yardstick CLI +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + See :doc:`04-installation` + +.. code-block:: console + + + docker exec -it yardstick /bin/bash + source /etc/yardstick/openstack.creds (only for heat TC if nsb_setup.sh was NOT used) + export EXTERNAL_NETWORK="<openstack public network>" (only for heat TC) + yardstick --debug task start yardstick/samples/vnf_samples/nsut/<vnf>/<test case> + +Network Service Benchmarking - Bare-Metal +----------------------------------------- + +Bare-Metal Config pod.yaml describing Topology +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Bare-Metal 2-Node setup: +######################## +.. code-block:: console + + +----------+ +----------+ + | | | | + | | (0)----->(0) | | + | TG1 | | DUT | + | | | | + | | (n)<-----(n) | | + +----------+ +----------+ + trafficgen_1 vnf + +Bare-Metal 3-Node setup - Correlated Traffic: +############################################# +.. code-block:: console + + +----------+ +----------+ +------------+ + | | | | | | + | | | | | | + | | (0)----->(0) | | | UDP | + | TG1 | | DUT | | Replay | + | | | | | | + | | | |(1)<---->(0)| | + +----------+ +----------+ +------------+ + trafficgen_1 vnf trafficgen_2 + + +Bare-Metal Config pod.yaml +^^^^^^^^^^^^^^^^^^^^^^^^^^ +Before executing Yardstick test cases, make sure that pod.yaml reflects the +topology and update all the required fields.:: + + cp /etc/yardstick/nodes/pod.yaml.nsb.sample /etc/yardstick/nodes/pod.yaml + +.. code-block:: YAML + + nodes: + - + name: trafficgen_1 + role: TrafficGen + ip: 1.1.1.1 + user: root + password: r00t + interfaces: + xe0: # logical name from topology.yaml and vnfd.yaml + vpci: "0000:07:00.0" + driver: i40e # default kernel driver + dpdk_port_num: 0 + local_ip: "152.16.100.20" + netmask: "255.255.255.0" + local_mac: "00:00:00:00:00:01" + xe1: # logical name from topology.yaml and vnfd.yaml + vpci: "0000:07:00.1" + driver: i40e # default kernel driver + dpdk_port_num: 1 + local_ip: "152.16.40.20" + netmask: "255.255.255.0" + local_mac: "00:00.00:00:00:02" + + - + name: vnf + role: vnf + ip: 1.1.1.2 + user: root + password: r00t + host: 1.1.1.2 #BM - host == ip, virtualized env - Host - compute node + interfaces: + xe0: # logical name from topology.yaml and vnfd.yaml + vpci: "0000:07:00.0" + driver: i40e # default kernel driver + dpdk_port_num: 0 + local_ip: "152.16.100.19" + netmask: "255.255.255.0" + local_mac: "00:00:00:00:00:03" + + xe1: # logical name from topology.yaml and vnfd.yaml + vpci: "0000:07:00.1" + driver: i40e # default kernel driver + dpdk_port_num: 1 + local_ip: "152.16.40.19" + netmask: "255.255.255.0" + local_mac: "00:00:00:00:00:04" + routing_table: + - network: "152.16.100.20" + netmask: "255.255.255.0" + gateway: "152.16.100.20" + if: "xe0" + - network: "152.16.40.20" + netmask: "255.255.255.0" + gateway: "152.16.40.20" + if: "xe1" + nd_route_tbl: + - network: "0064:ff9b:0:0:0:0:9810:6414" + netmask: "112" + gateway: "0064:ff9b:0:0:0:0:9810:6414" + if: "xe0" + - network: "0064:ff9b:0:0:0:0:9810:2814" + netmask: "112" + gateway: "0064:ff9b:0:0:0:0:9810:2814" + if: "xe1" + + +Network Service Benchmarking - Standalone Virtualization +-------------------------------------------------------- + +SR-IOV: +^^^^^^^ + +SR-IOV Pre-requisites +##################### + +On Host: + a) Create a bridge for VM to connect to external network + + .. code-block:: console + + brctl addbr br-int + brctl addif br-int <interface_name> #This interface is connected to internet + + b) Build guest image for VNF to run. + Most of the sample test cases in Yardstick are using a guest image called + ``yardstick-image`` which deviates from an Ubuntu Cloud Server image + Yardstick has a tool for building this custom image with samplevnf. + It is necessary to have ``sudo`` rights to use this tool. + + Also you may need to install several additional packages to use this tool, by + following the commands below:: + + sudo apt-get update && sudo apt-get install -y qemu-utils kpartx + + This image can be built using the following command in the directory where Yardstick is installed + + .. code-block:: console + + export YARD_IMG_ARCH='amd64' + sudo echo "Defaults env_keep += \'YARD_IMG_ARCH\'" >> /etc/sudoers + + Please use ansible script to generate a cloud image refer to :doc:`04-installation` + + for more details refer to chapter :doc:`04-installation` + + .. note:: VM should be build with static IP and should be accessible from yardstick host. + + +SR-IOV Config pod.yaml describing Topology +########################################## + +SR-IOV 2-Node setup: +#################### +.. code-block:: console + + +--------------------+ + | | + | | + | DUT | + | (VNF) | + | | + +--------------------+ + | VF NIC | | VF NIC | + +--------+ +--------+ + ^ ^ + | | + | | + +----------+ +-------------------------+ + | | | ^ ^ | + | | | | | | + | | (0)<----->(0) | ------ | | + | TG1 | | SUT | | + | | | | | + | | (n)<----->(n) |------------------ | + +----------+ +-------------------------+ + trafficgen_1 host + + + +SR-IOV 3-Node setup - Correlated Traffic +######################################## +.. code-block:: console + + +--------------------+ + | | + | | + | DUT | + | (VNF) | + | | + +--------------------+ + | VF NIC | | VF NIC | + +--------+ +--------+ + ^ ^ + | | + | | + +----------+ +-------------------------+ +--------------+ + | | | ^ ^ | | | + | | | | | | | | + | | (0)<----->(0) | ------ | | | TG2 | + | TG1 | | SUT | | | (UDP Replay) | + | | | | | | | + | | (n)<----->(n) | ------ | (n)<-->(n) | | + +----------+ +-------------------------+ +--------------+ + trafficgen_1 host trafficgen_2 + +Before executing Yardstick test cases, make sure that pod.yaml reflects the +topology and update all the required fields. + +.. code-block:: console + + cp <yardstick>/etc/yardstick/nodes/standalone/trex_bm.yaml.sample /etc/yardstick/nodes/standalone/pod_trex.yaml + cp <yardstick>/etc/yardstick/nodes/standalone/host_sriov.yaml /etc/yardstick/nodes/standalone/host_sriov.yaml + +.. note:: Update all the required fields like ip, user, password, pcis, etc... + +SR-IOV Config pod_trex.yaml +########################### + +.. code-block:: YAML + + nodes: + - + name: trafficgen_1 + role: TrafficGen + ip: 1.1.1.1 + user: root + password: r00t + key_filename: /root/.ssh/id_rsa + interfaces: + xe0: # logical name from topology.yaml and vnfd.yaml + vpci: "0000:07:00.0" + driver: i40e # default kernel driver + dpdk_port_num: 0 + local_ip: "152.16.100.20" + netmask: "255.255.255.0" + local_mac: "00:00:00:00:00:01" + xe1: # logical name from topology.yaml and vnfd.yaml + vpci: "0000:07:00.1" + driver: i40e # default kernel driver + dpdk_port_num: 1 + local_ip: "152.16.40.20" + netmask: "255.255.255.0" + local_mac: "00:00.00:00:00:02" + +SR-IOV Config host_sriov.yaml +############################# + +.. code-block:: YAML + + nodes: + - + name: sriov + role: Sriov + ip: 192.168.100.101 + user: "" + password: "" + +SR-IOV testcase update: ``<yardstick>/samples/vnf_samples/nsut/vfw/tc_sriov_rfc2544_ipv4_1rule_1flow_64B_trex.yaml`` + +Update "contexts" section +""""""""""""""""""""""""" + +.. code-block:: YAML + + contexts: + - name: yardstick + type: Node + file: /etc/yardstick/nodes/standalone/pod_trex.yaml + - type: StandaloneSriov + file: /etc/yardstick/nodes/standalone/host_sriov.yaml + name: yardstick + vm_deploy: True + flavor: + images: "/var/lib/libvirt/images/ubuntu.qcow2" + ram: 4096 + extra_specs: + hw:cpu_sockets: 1 + hw:cpu_cores: 6 + hw:cpu_threads: 2 + user: "" # update VM username + password: "" # update password + servers: + vnf: + network_ports: + mgmt: + cidr: '1.1.1.61/24' # Update VM IP address, if static, <ip>/<mask> or if dynamic, <start of ip>/<mask> + xe0: + - uplink_0 + xe1: + - downlink_0 + networks: + uplink_0: + phy_port: "0000:05:00.0" + vpci: "0000:00:07.0" + cidr: '152.16.100.10/24' + gateway_ip: '152.16.100.20' + downlink_0: + phy_port: "0000:05:00.1" + vpci: "0000:00:08.0" + cidr: '152.16.40.10/24' + gateway_ip: '152.16.100.20' + + + +OVS-DPDK: +^^^^^^^^^ + +OVS-DPDK Pre-requisites +####################### + +On Host: + a) Create a bridge for VM to connect to external network + + .. code-block:: console + + brctl addbr br-int + brctl addif br-int <interface_name> #This interface is connected to internet + + b) Build guest image for VNF to run. + Most of the sample test cases in Yardstick are using a guest image called + ``yardstick-image`` which deviates from an Ubuntu Cloud Server image + Yardstick has a tool for building this custom image with samplevnf. + It is necessary to have ``sudo`` rights to use this tool. + + Also you may need to install several additional packages to use this tool, by + following the commands below:: + + sudo apt-get update && sudo apt-get install -y qemu-utils kpartx + + This image can be built using the following command in the directory where Yardstick is installed:: + + export YARD_IMG_ARCH='amd64' + sudo echo "Defaults env_keep += \'YARD_IMG_ARCH\'" >> /etc/sudoers + sudo tools/yardstick-img-dpdk-modify tools/ubuntu-server-cloudimg-samplevnf-modify.sh + + for more details refer to chapter :doc:`04-installation` + + .. note:: VM should be build with static IP and should be accessible from yardstick host. + + c) OVS & DPDK version. + - OVS 2.7 and DPDK 16.11.1 above version is supported + + d) Setup OVS/DPDK on host. + Please refer to below link on how to setup `OVS-DPDK <http://docs.openvswitch.org/en/latest/intro/install/dpdk/>`_ + + +OVS-DPDK Config pod.yaml describing Topology +############################################ + +OVS-DPDK 2-Node setup: +###################### + + +.. code-block:: console + + +--------------------+ + | | + | | + | DUT | + | (VNF) | + | | + +--------------------+ + | virtio | | virtio | + +--------+ +--------+ + ^ ^ + | | + | | + +--------+ +--------+ + | vHOST0 | | vHOST1 | + +----------+ +-------------------------+ + | | | ^ ^ | + | | | | | | + | | (0)<----->(0) | ------ | | + | TG1 | | SUT | | + | | | (ovs-dpdk) | | + | | (n)<----->(n) |------------------ | + +----------+ +-------------------------+ + trafficgen_1 host + + +OVS-DPDK 3-Node setup - Correlated Traffic +########################################## + +.. code-block:: console + + +--------------------+ + | | + | | + | DUT | + | (VNF) | + | | + +--------------------+ + | virtio | | virtio | + +--------+ +--------+ + ^ ^ + | | + | | + +--------+ +--------+ + | vHOST0 | | vHOST1 | + +----------+ +-------------------------+ +------------+ + | | | ^ ^ | | | + | | | | | | | | + | | (0)<----->(0) | ------ | | | TG2 | + | TG1 | | SUT | | |(UDP Replay)| + | | | (ovs-dpdk) | | | | + | | (n)<----->(n) | ------ |(n)<-->(n)| | + +----------+ +-------------------------+ +------------+ + trafficgen_1 host trafficgen_2 + + +Before executing Yardstick test cases, make sure that pod.yaml reflects the +topology and update all the required fields. + +.. code-block:: console + + cp <yardstick>/etc/yardstick/nodes/standalone/trex_bm.yaml.sample /etc/yardstick/nodes/standalone/pod_trex.yaml + cp <yardstick>/etc/yardstick/nodes/standalone/host_ovs.yaml /etc/yardstick/nodes/standalone/host_ovs.yaml + +.. note:: Update all the required fields like ip, user, password, pcis, etc... + +OVS-DPDK Config pod_trex.yaml +############################# + +.. code-block:: YAML + + nodes: + - + name: trafficgen_1 + role: TrafficGen + ip: 1.1.1.1 + user: root + password: r00t + interfaces: + xe0: # logical name from topology.yaml and vnfd.yaml + vpci: "0000:07:00.0" + driver: i40e # default kernel driver + dpdk_port_num: 0 + local_ip: "152.16.100.20" + netmask: "255.255.255.0" + local_mac: "00:00:00:00:00:01" + xe1: # logical name from topology.yaml and vnfd.yaml + vpci: "0000:07:00.1" + driver: i40e # default kernel driver + dpdk_port_num: 1 + local_ip: "152.16.40.20" + netmask: "255.255.255.0" + local_mac: "00:00.00:00:00:02" + +OVS-DPDK Config host_ovs.yaml +############################# + +.. code-block:: YAML + + nodes: + - + name: ovs_dpdk + role: OvsDpdk + ip: 192.168.100.101 + user: "" + password: "" + +ovs_dpdk testcase update: ``<yardstick>/samples/vnf_samples/nsut/vfw/tc_ovs_rfc2544_ipv4_1rule_1flow_64B_trex.yaml`` + +Update "contexts" section +""""""""""""""""""""""""" + +.. code-block:: YAML + + contexts: + - name: yardstick + type: Node + file: /etc/yardstick/nodes/standalone/pod_trex.yaml + - type: StandaloneOvsDpdk + name: yardstick + file: /etc/yardstick/nodes/standalone/pod_ovs.yaml + vm_deploy: True + ovs_properties: + version: + ovs: 2.7.0 + dpdk: 16.11.1 + pmd_threads: 2 + ram: + socket_0: 2048 + socket_1: 2048 + queues: 4 + vpath: "/usr/local" + + flavor: + images: "/var/lib/libvirt/images/ubuntu.qcow2" + ram: 4096 + extra_specs: + hw:cpu_sockets: 1 + hw:cpu_cores: 6 + hw:cpu_threads: 2 + user: "" # update VM username + password: "" # update password + servers: + vnf: + network_ports: + mgmt: + cidr: '1.1.1.61/24' # Update VM IP address, if static, <ip>/<mask> or if dynamic, <start of ip>/<mask> + xe0: + - uplink_0 + xe1: + - downlink_0 + networks: + uplink_0: + phy_port: "0000:05:00.0" + vpci: "0000:00:07.0" + cidr: '152.16.100.10/24' + gateway_ip: '152.16.100.20' + downlink_0: + phy_port: "0000:05:00.1" + vpci: "0000:00:08.0" + cidr: '152.16.40.10/24' + gateway_ip: '152.16.100.20' + + +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`` + 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 + to /usr/bin/ixiapython<ver> inside the container. + +2. Update pod_ixia.yaml file with ixia details. + + .. code-block:: console + + cp <repo>/etc/yardstick/nodes/pod.yaml.nsb.sample.ixia etc/yardstick/nodes/pod_ixia.yaml + + Config pod_ixia.yaml + + .. code-block:: yaml + + + nodes: + - + name: trafficgen_1 + role: IxNet + ip: 1.2.1.1 #ixia machine ip + user: user + password: r00t + key_filename: /root/.ssh/id_rsa + tg_config: + ixchassis: "1.2.1.7" #ixia chassis ip + tcl_port: "8009" # tcl server port + lib_path: "/opt/ixia/ixos-api/8.01.0.2/lib/ixTcl1.0" + root_dir: "/opt/ixia/ixos-api/8.01.0.2/" + py_bin_path: "/opt/ixia/ixload/8.01.106.3/bin/" + py_lib_path: "/opt/ixia/ixnetwork/8.01.1029.14/lib/PythonApi" + dut_result_dir: "/mnt/ixia" + version: 8.1 + interfaces: + xe0: # logical name from topology.yaml and vnfd.yaml + vpci: "2:5" # Card:port + driver: "none" + dpdk_port_num: 0 + local_ip: "152.16.100.20" + netmask: "255.255.0.0" + local_mac: "00:98:10:64:14:00" + xe1: # logical name from topology.yaml and vnfd.yaml + vpci: "2:6" # [(Card, port)] + driver: "none" + dpdk_port_num: 1 + local_ip: "152.40.40.20" + netmask: "255.255.0.0" + local_mac: "00:98:28:28:14:00" + + for sriov/ovs_dpdk pod files, please refer to above Standalone Virtualization for ovs-dpdk/sriov configuration + +3. Start IxOS TCL Server (Install 'Ixia IxExplorer IxOS <version>') + You will also need to configure the IxLoad machine to start the IXIA + IxosTclServer. This can be started like so: + + - 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`` + or + ``"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. + +5. execute testcase in samplevnf folder. + eg ``<repo>/samples/vnf_samples/nsut/vfw/tc_baremetal_http_ixload_1b_Requests-65000_Concurrency.yaml`` + +IxNetwork: +^^^^^^^^^^ + +1. Software needed: ``IxNetworkAPI<ixnetwork verson>Linux64.bin.tgz`` (Download from ixia support site) + Install - ``IxNetworkAPI<ixnetwork verson>Linux64.bin.tgz`` +2. Update pod_ixia.yaml file with ixia details. + + .. code-block:: console + + cp <repo>/etc/yardstick/nodes/pod.yaml.nsb.sample.ixia etc/yardstick/nodes/pod_ixia.yaml + + Config pod_ixia.yaml + + .. code-block:: yaml + + nodes: + - + name: trafficgen_1 + role: IxNet + ip: 1.2.1.1 #ixia machine ip + user: user + password: r00t + key_filename: /root/.ssh/id_rsa + tg_config: + ixchassis: "1.2.1.7" #ixia chassis ip + tcl_port: "8009" # tcl server port + lib_path: "/opt/ixia/ixos-api/8.01.0.2/lib/ixTcl1.0" + root_dir: "/opt/ixia/ixos-api/8.01.0.2/" + py_bin_path: "/opt/ixia/ixload/8.01.106.3/bin/" + py_lib_path: "/opt/ixia/ixnetwork/8.01.1029.14/lib/PythonApi" + dut_result_dir: "/mnt/ixia" + version: 8.1 + interfaces: + xe0: # logical name from topology.yaml and vnfd.yaml + vpci: "2:5" # Card:port + driver: "none" + dpdk_port_num: 0 + local_ip: "152.16.100.20" + netmask: "255.255.0.0" + local_mac: "00:98:10:64:14:00" + xe1: # logical name from topology.yaml and vnfd.yaml + vpci: "2:6" # [(Card, port)] + driver: "none" + dpdk_port_num: 1 + local_ip: "152.40.40.20" + netmask: "255.255.0.0" + local_mac: "00:98:28:28:14:00" + + for sriov/ovs_dpdk pod files, please refer to above Standalone Virtualization for ovs-dpdk/sriov configuration + +3. Start IxNetwork TCL Server + You will also need to configure the IxNetwork machine to start the IXIA + IxNetworkTclServer. This can be started like so: + + - Connect to the IxNetwork machine using RDP + - Go to: ``Start->Programs->Ixia->IxNetwork->IxNetwork 7.21.893.14 GA->IxNetworkTclServer`` (or ``IxNetworkApiServer``) + +4. execute testcase in samplevnf folder. + eg ``<repo>/samples/vnf_samples/nsut/vfw/tc_baremetal_rfc2544_ipv4_1rule_1flow_64B_ixia.yaml`` + diff --git a/docs/testing/user/userguide/13-nsb_operation.rst b/docs/testing/user/userguide/13-nsb_operation.rst new file mode 100644 index 000000000..8c477fa3f --- /dev/null +++ b/docs/testing/user/userguide/13-nsb_operation.rst @@ -0,0 +1,270 @@ +.. 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. + +Yardstick - NSB Testing - Operation +=================================== + +Abstract +-------- + +NSB test configuration and OpenStack setup requirements + + +OpenStack Network Configuration +------------------------------- + +NSB requires certain OpenStack deployment configurations. +For optimal VNF characterization using external traffic generators NSB requires +provider/external networks. + + +Provider networks +^^^^^^^^^^^^^^^^^ + +The VNFs require a clear L2 connect to the external network in order to generate +realistic traffic from multiple address ranges and port + +In order to prevent Neutron from filtering traffic we have to disable Neutron Port Security. +We also disable DHCP on the data ports because we are binding the ports to DPDK and do not need +DHCP addresses. We also disable gateways because multiple default gateways can prevent SSH access +to the VNF from the floating IP. We only want a gateway on the mgmt network + +.. code-block:: yaml + + uplink_0: + cidr: '10.1.0.0/24' + gateway_ip: 'null' + port_security_enabled: False + enable_dhcp: 'false' + +Heat Topologies +^^^^^^^^^^^^^^^ + +By default Heat will attach every node to every Neutron network that is created. +For scale-out tests we do not want to attach every node to every network. + +For each node you can specify which ports are on which network using the +network_ports dictionary. + +In this example we have ``TRex xe0 <-> xe0 VNF xe1 <-> xe0 UDP_Replay`` + +.. code-block:: yaml + + vnf_0: + floating_ip: true + placement: "pgrp1" + network_ports: + mgmt: + - mgmt + uplink_0: + - xe0 + downlink_0: + - xe1 + tg_0: + floating_ip: true + placement: "pgrp1" + network_ports: + mgmt: + - mgmt + uplink_0: + - xe0 + # Trex always needs two ports + uplink_1: + - xe1 + tg_1: + floating_ip: true + placement: "pgrp1" + network_ports: + mgmt: + - mgmt + downlink_0: + - xe0 + +Collectd KPIs +------------- + +NSB can collect KPIs from collected. We have support for various plugins enabled by the +Barometer project. + +The default yardstick-samplevnf has collectd installed. This allows for collecting KPIs +from the VNF. + +Collecting KPIs from the NFVi is more complicated and requires manual setup. +We assume that collectd is not installed on the compute nodes. + +To collectd KPIs from the NFVi compute nodes: + + + * install_collectd on the compute nodes + * create pod.yaml for the compute nodes + * enable specific plugins depending on the vswitch and DPDK + + example pod.yaml section for Compute node running collectd. + +.. code-block:: yaml + + - + name: "compute-1" + role: Compute + ip: "10.1.2.3" + user: "root" + ssh_port: "22" + password: "" + collectd: + interval: 5 + plugins: + # for libvirtd stats + virt: {} + intel_pmu: {} + ovs_stats: + # path to OVS socket + ovs_socket_path: /var/run/openvswitch/db.sock + intel_rdt: {} + + + +Scale-Up +------------------ + +VNFs performance data with scale-up + + * Helps to figure out optimal number of cores specification in the Virtual Machine template creation or VNF + * Helps in comparison between different VNF vendor offerings + * Better the scale-up index, indicates the performance scalability of a particular solution + +Heat +^^^^ + +For VNF scale-up tests we increase the number for VNF worker threads. 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: + +.. code-block:: console + + <repo>/samples/vnf_samples/nsut/acl/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 + +.. code-block:: console + + 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 + + +Baremetal +^^^^^^^^^ + 1. Follow above traffic generator section to setup. + 2. edit num of threads in ``<repo>/samples/vnf_samples/nsut/vfw/tc_baremetal_rfc2544_ipv4_1rule_1flow_64B_trex_scale_up.yaml`` + + e.g, 6 Threads for given VNF + +.. code-block:: yaml + + + schema: yardstick:task:0.1 + scenarios: + {% for worker_thread in [1, 2 ,3 , 4, 5, 6] %} + - type: NSPerf + traffic_profile: ../../traffic_profiles/ipv4_throughput.yaml + topology: vfw-tg-topology.yaml + nodes: + tg__0: trafficgen_1.yardstick + vnf__0: vnf.yardstick + options: + framesize: + uplink: {64B: 100} + downlink: {64B: 100} + flow: + src_ip: [{'tg__0': 'xe0'}] + dst_ip: [{'tg__0': 'xe1'}] + count: 1 + traffic_type: 4 + rfc2544: + allowed_drop_rate: 0.0001 - 0.0001 + vnf__0: + rules: acl_1rule.yaml + vnf_config: {lb_config: 'HW', lb_count: 1, worker_config: '1C/1T', worker_threads: {{worker_thread}}} + nfvi_enable: True + runner: + type: Iteration + iterations: 10 + interval: 35 + {% endfor %} + context: + type: Node + name: yardstick + nfvi_type: baremetal + file: /etc/yardstick/nodes/pod.yaml + +Scale-Out +-------------------- + +VNFs performance data with scale-out + + * Helps in capacity planning to meet the given network node requirements + * Helps in comparison between different VNF vendor offerings + * Better the scale-out index, provides the flexibility in meeting future capacity requirements + + +Standalone +^^^^^^^^^^ + +Scale-out not supported on Baremetal. + +1. Follow above traffic generator section to setup. +2. Generate testcase for standalone virtualization using ansible scripts + + .. code-block:: console + + cd <repo>/ansible + trex: standalone_ovs_scale_out_trex_test.yaml or standalone_sriov_scale_out_trex_test.yaml + ixia: standalone_ovs_scale_out_ixia_test.yaml or standalone_sriov_scale_out_ixia_test.yaml + ixia_correlated: standalone_ovs_scale_out_ixia_correlated_test.yaml or standalone_sriov_scale_out_ixia_correlated_test.yaml + + update the ovs_dpdk or sriov above Ansible scripts reflect the setup + +3. run the test + + .. code-block:: console + + <repo>/samples/vnf_samples/nsut/tc_sriov_vfw_udp_ixia_correlated_scale_out-1.yaml + <repo>/samples/vnf_samples/nsut/tc_sriov_vfw_udp_ixia_correlated_scale_out-2.yaml + +Heat +^^^^ + +There are sample scale-out all-VM Heat tests. These tests only use VMs and don't use external traffic. + +The tests use UDP_Replay and correlated traffic. + +.. code-block:: console + + <repo>/samples/vnf_samples/nsut/cgnapt/tc_heat_rfc2544_ipv4_1flow_64B_trex_correlated_scale_4.yaml + +To run the test you need to increase OpenStack CPU, Memory and Port quotas. + + +Traffic Generator tuning +------------------------ + +The TRex traffic generator can be setup to use multiple threads per core, this is for multiqueue testing. + +TRex does not automatically enable multiple threads because we currently cannot detect the number of queues on a device. + +To enable multiple queue set the queues_per_port value in the TG VNF options section. + +.. code-block:: yaml + + scenarios: + - type: NSPerf + nodes: + tg__0: tg_0.yardstick + + options: + tg_0: + queues_per_port: 2 + + diff --git a/docs/testing/user/userguide/14-nsb_installation.rst b/docs/testing/user/userguide/14-nsb_installation.rst deleted file mode 100644 index 39477f476..000000000 --- a/docs/testing/user/userguide/14-nsb_installation.rst +++ /dev/null @@ -1,737 +0,0 @@ -.. 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. - -Yardstick - NSB Testing -Installation -===================================== - -Abstract --------- - -The Network Service Benchmarking (NSB) extends the yardstick framework to do -VNF characterization and benchmarking in three different execution -environments viz., bare metal i.e. native Linux environment, standalone virtual -environment and managed virtualized environment (e.g. Open stack etc.). -It also brings in the capability to interact with external traffic generators -both hardware & software based for triggering and validating the traffic -according to user defined profiles. - -The steps needed to run Yardstick with NSB testing are: - -* Install Yardstick (NSB Testing). -* Setup pod.yaml describing Test topology -* Create the test configuration yaml file. -* Run the test case. - - -Prerequisites -------------- - -Refer chapter Yardstick Instalaltion for more information on yardstick -prerequisites - -Several prerequisites are needed for Yardstick(VNF testing): - -- Python Modules: pyzmq, pika. - -- flex - -- bison - -- build-essential - -- automake - -- libtool - -- librabbitmq-dev - -- rabbitmq-server - -- collectd - -- intel-cmt-cat - -Install Yardstick (NSB Testing) -------------------------------- - -Using Docker ------------- -Refer chapter :doc:`04-installation` for more on docker **Install Yardstick using Docker (**recommended**)** - -Install directly in Ubuntu --------------------------- -.. _install-framework: - -Alternatively you can install Yardstick framework directly in Ubuntu or in an Ubuntu Docker image. No matter which way you choose to install Yardstick, the following installation steps are identical. - -If you choose to use the Ubuntu Docker image, you can pull the Ubuntu -Docker image from Docker hub:: - - docker pull ubuntu:16.04 - -Install Yardstick -^^^^^^^^^^^^^^^^^^^^^ - -Prerequisite preparation:: - - apt-get update && apt-get install -y git python-setuptools python-pip - easy_install -U setuptools==30.0.0 - pip install appdirs==1.4.0 - pip install virtualenv - -Create a virtual environment:: - - virtualenv ~/yardstick_venv - export YARDSTICK_VENV=~/yardstick_venv - source ~/yardstick_venv/bin/activate - -Download the source code and install Yardstick from it:: - - git clone https://gerrit.opnfv.org/gerrit/yardstick - export YARDSTICK_REPO_DIR=~/yardstick - cd yardstick - ./install.sh - - -After *Yardstick* is installed, executing the "nsb_setup.sh" script to setup -NSB testing:: - - ./nsb_setup.sh - -It will also automatically download all the packages needed for NSB Testing setup. - -System Topology: ------------------ - -.. code-block:: console - - +----------+ +----------+ - | | | | - | | (0)----->(0) | | - | TG1 | | DUT | - | | | | - | | (1)<-----(1) | | - +----------+ +----------+ - trafficgen_1 vnf - - -Environment parameters and credentials --------------------------------------- - -Environment variables -^^^^^^^^^^^^^^^^^^^^^ - -Before running Yardstick (NSB Testing) it is necessary to export traffic -generator libraries.:: - - source ~/.bash_profile - -Config yardstick conf -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - cp ./etc/yardstick/yardstick.conf.sample /etc/yardstick/yardstick.conf - vi /etc/yardstick/yardstick.conf - -Add trex_path, trex_client_lib and bin_path in 'nsb' section. - -:: - - [DEFAULT] - debug = True - dispatcher = file, influxdb - - [dispatcher_influxdb] - timeout = 5 - target = http://{YOUR_IP_HERE}:8086 - db_name = yardstick - username = root - password = root - - [nsb] - trex_path=/opt/nsb_bin/trex/scripts - bin_path=/opt/nsb_bin - trex_client_lib=/opt/nsb_bin/trex_client/stl - -Network Service Benchmarking - Bare-Metal ------------------------------------------ - -Config pod.yaml describing Topology -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -2-Node setup: -^^^^^^^^^^^^^ -.. code-block:: console - +----------+ +----------+ - | | | | - | | (0)----->(0) | | - | TG1 | | DUT | - | | | | - | | (n)<-----(n) | | - +----------+ +----------+ - trafficgen_1 vnf - -3-Node setup - Correlated Traffic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. code-block:: console - +----------+ +----------+ +------------+ - | | | | | | - | | | | | | - | | (0)----->(0) | | | UDP | - | TG1 | | DUT | | Replay | - | | | | | | - | | | |(1)<---->(0)| | - +----------+ +----------+ +------------+ - trafficgen_1 vnf trafficgen_2 - -Before executing Yardstick test cases, make sure that pod.yaml reflects the -topology and update all the required fields.:: - - cp /etc/yardstick/nodes/pod.yaml.nsb.sample /etc/yardstick/nodes/pod.yaml - -Config pod.yaml -:: - nodes: - - - name: trafficgen_1 - role: TrafficGen - ip: 1.1.1.1 - user: root - password: r00t - interfaces: - xe0: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:07:00.0" - driver: i40e # default kernel driver - dpdk_port_num: 0 - local_ip: "152.16.100.20" - netmask: "255.255.255.0" - local_mac: "00:00:00:00:00:01" - xe1: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:07:00.1" - driver: i40e # default kernel driver - dpdk_port_num: 1 - local_ip: "152.16.40.20" - netmask: "255.255.255.0" - local_mac: "00:00.00:00:00:02" - - - - name: vnf - role: vnf - ip: 1.1.1.2 - user: root - password: r00t - host: 1.1.1.2 #BM - host == ip, virtualized env - Host - compute node - interfaces: - xe0: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:07:00.0" - driver: i40e # default kernel driver - dpdk_port_num: 0 - local_ip: "152.16.100.19" - netmask: "255.255.255.0" - local_mac: "00:00:00:00:00:03" - - xe1: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:07:00.1" - driver: i40e # default kernel driver - dpdk_port_num: 1 - local_ip: "152.16.40.19" - netmask: "255.255.255.0" - local_mac: "00:00:00:00:00:04" - routing_table: - - network: "152.16.100.20" - netmask: "255.255.255.0" - gateway: "152.16.100.20" - if: "xe0" - - network: "152.16.40.20" - netmask: "255.255.255.0" - gateway: "152.16.40.20" - if: "xe1" - nd_route_tbl: - - network: "0064:ff9b:0:0:0:0:9810:6414" - netmask: "112" - gateway: "0064:ff9b:0:0:0:0:9810:6414" - if: "xe0" - - network: "0064:ff9b:0:0:0:0:9810:2814" - netmask: "112" - gateway: "0064:ff9b:0:0:0:0:9810:2814" - if: "xe1" - -Enable yardstick virtual environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Before executing yardstick test cases, make sure to activate yardstick -python virtual environment if runnin on ubuntu without docker:: - - source /opt/nsb_bin/yardstick_venv/bin/activate - -On docker, virtual env is in main path. - -Run Yardstick - Network Service Testcases ------------------------------------------ - -NS testing - using NSBperf CLI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - PYTHONPATH: ". ~/.bash_profile" - cd <yardstick_repo>/yardstick/cmd - - Execute command: ./NSPerf.py -h - ./NSBperf.py --vnf <selected vnf> --test <rfc test> - eg: ./NSBperf.py --vnf vpe --test tc_baremetal_rfc2544_ipv4_1flow_64B.yaml - -NS testing - using yardstick CLI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - PYTHONPATH: ". ~/.bash_profile" - -Go to test case forlder type we want to execute. - e.g. <yardstick repo>/samples/vnf_samples/nsut/<vnf>/ - run: yardstick --debug task start <test_case.yaml> - -Network Service Benchmarking - Standalone Virtualization --------------------------------------------------------- - -SRIOV: ------ - -Pre-requisites -^^^^^^^^^^^^^^ - -On Host: - a) Create a bridge for VM to connect to external network - brctl addbr br-int - brctl addif br-int <interface_name> #This interface is connected to internet - - b) Build guest image for VNF to run. - Most of the sample test cases in Yardstick are using a guest image called - ``yardstick-image`` which deviates from an Ubuntu Cloud Server image - Yardstick has a tool for building this custom image with samplevnf. - It is necessary to have ``sudo`` rights to use this tool. - - Also you may need to install several additional packages to use this tool, by - follwing the commands below:: - - sudo apt-get update && sudo apt-get install -y qemu-utils kpartx - - This image can be built using the following command in the directory where Yardstick is installed:: - - export YARD_IMG_ARCH='amd64' - sudo echo "Defaults env_keep += \'YARD_IMG_ARCH\'" >> /etc/sudoers - sudo tools/yardstick-img-dpdk-modify tools/ubuntu-server-cloudimg-samplevnf-modify.sh - - for more details refer chapter :doc:`04-installation`` - -Note: VM should be build with static IP and should be accessiable from yardstick host. - -Config pod.yaml describing Topology -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -2-Node setup: -^^^^^^^^^^^^^ -.. code-block:: console - +--------------------+ - | | - | | - | DUT | - | (VNF) | - | | - +--------------------+ - | VF NIC | | VF NIC | - +--------+ +--------+ - ^ ^ - | | - | | - +--------+ +--------+ - - PF NIC - - PF NIC - - +----------+ +-------------------------+ - | | | ^ ^ | - | | | | | | - | | (0)<----->(0) | ------ | | - | TG1 | | SUT | | - | | | | | - | | (n)<----->(n) |------------------ | - +----------+ +-------------------------+ - trafficgen_1 host - - -3-Node setup - Correlated Traffic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. code-block:: console - - +--------------------+ - | | - | | - | DUT | - | (VNF) | - | | - +--------------------+ - | VF NIC | | VF NIC | - +--------+ +--------+ - ^ ^ - | | - | | - +--------+ +--------+ - | PF NIC - - PF NIC - - +----------+ +-------------------------+ +------------+ - | | | ^ ^ | | | - | | | | | | | | - | | (0)<----->(0) | ------ | | | TG2 | - | TG1 | | SUT | | |(UDP Replay)| - | | | | | | | - | | (n)<----->(n) | ------ |(n)<-->(n)| | - +----------+ +-------------------------+ +------------+ - trafficgen_1 host trafficgen_2 - -Before executing Yardstick test cases, make sure that pod.yaml reflects the -topology and update all the required fields. - -:: - - cp /etc/yardstick/nodes/pod.yaml.nsb.sriov.sample /etc/yardstick/nodes/pod.yaml - -Config pod.yaml -:: - nodes: - - - name: trafficgen_1 - role: TrafficGen - ip: 1.1.1.1 - user: root - password: r00t - interfaces: - xe0: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:07:00.0" - driver: i40e # default kernel driver - dpdk_port_num: 0 - local_ip: "152.16.100.20" - netmask: "255.255.255.0" - local_mac: "00:00:00:00:00:01" - xe1: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:07:00.1" - driver: i40e # default kernel driver - dpdk_port_num: 1 - local_ip: "152.16.40.20" - netmask: "255.255.255.0" - local_mac: "00:00.00:00:00:02" - -- - name: sriov - role: Sriov - ip: 2.2.2.2 - user: root - auth_type: password - password: password - vf_macs: - - "00:00:00:00:00:03" - - "00:00:00:00:00:04" - phy_ports: # Physical ports to configure sriov - - "0000:06:00.0" - - "0000:06:00.1" - phy_driver: i40e # kernel driver - images: "/var/lib/libvirt/images/ubuntu1.img" - - - - name: vnf - role: vnf - ip: 1.1.1.2 - user: root - password: r00t - host: 2.2.2.2 #BM - host == ip, virtualized env - Host - compute node - interfaces: - xe0: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:00:07.0" - driver: i40evf # default kernel driver - dpdk_port_num: 0 - local_ip: "152.16.100.10" - netmask: "255.255.255.0" - local_mac: "00:00:00:00:00:03" - - xe1: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:00:08.0" - driver: i40evf # default kernel driver - dpdk_port_num: 1 - local_ip: "152.16.40.10" - netmask: "255.255.255.0" - local_mac: "00:00:00:00:00:04" - routing_table: - - network: "152.16.100.10" - netmask: "255.255.255.0" - gateway: "152.16.100.20" - if: "xe0" - - network: "152.16.40.10" - netmask: "255.255.255.0" - gateway: "152.16.40.20" - if: "xe1" - nd_route_tbl: - - network: "0064:ff9b:0:0:0:0:9810:6414" - netmask: "112" - gateway: "0064:ff9b:0:0:0:0:9810:6414" - if: "xe0" - - network: "0064:ff9b:0:0:0:0:9810:2814" - netmask: "112" - gateway: "0064:ff9b:0:0:0:0:9810:2814" - if: "xe1" - -Enable yardstick virtual environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Before executing yardstick test cases, make sure to activate yardstick -python virtual environment if runnin on ubuntu without docker:: - - source /opt/nsb_bin/yardstick_venv/bin/activate - -On docker, virtual env is in main path. - -Run Yardstick - Network Service Testcases ------------------------------------------ - -NS testing - using NSBperf CLI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - PYTHONPATH: ". ~/.bash_profile" - cd <yardstick_repo>/yardstick/cmd - - Execute command: ./NSPerf.py -h - ./NSBperf.py --vnf <selected vnf> --test <rfc test> - eg: ./NSBperf.py --vnf vfw --test tc_sriov_rfc2544_ipv4_1flow_64B.yaml - -NS testing - using yardstick CLI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - PYTHONPATH: ". ~/.bash_profile" - -Go to test case forlder type we want to execute. - e.g. <yardstick repo>/samples/vnf_samples/nsut/<vnf>/ - run: yardstick --debug task start <test_case.yaml> - -OVS-DPDK: ------ - -Pre-requisites -^^^^^^^^^^^^^^ - -On Host: - a) Create a bridge for VM to connect to external network - brctl addbr br-int - brctl addif br-int <interface_name> #This interface is connected to internet - - b) Build guest image for VNF to run. - Most of the sample test cases in Yardstick are using a guest image called - ``yardstick-image`` which deviates from an Ubuntu Cloud Server image - Yardstick has a tool for building this custom image with samplevnf. - It is necessary to have ``sudo`` rights to use this tool. - - Also you may need to install several additional packages to use this tool, by - follwing the commands below:: - - sudo apt-get update && sudo apt-get install -y qemu-utils kpartx - - This image can be built using the following command in the directory where Yardstick is installed:: - - export YARD_IMG_ARCH='amd64' - sudo echo "Defaults env_keep += \'YARD_IMG_ARCH\'" >> /etc/sudoers - sudo tools/yardstick-img-dpdk-modify tools/ubuntu-server-cloudimg-samplevnf-modify.sh - - for more details refer chapter :doc:`04-installation`` - -Note: VM should be build with static IP and should be accessiable from yardstick host. - - c) OVS & DPDK version. - - OVS 2.7 and DPDK 16.11.1 above version is supported - - d) Setup OVS/DPDK on host. - Please refer below link on how to setup .. _ovs-dpdk: http://docs.openvswitch.org/en/latest/intro/install/dpdk/ - -Config pod.yaml describing Topology -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -2-Node setup: -^^^^^^^^^^^^^ -.. code-block:: console - +--------------------+ - | | - | | - | DUT | - | (VNF) | - | | - +--------------------+ - | virtio | | virtio | - +--------+ +--------+ - ^ ^ - | | - | | - +--------+ +--------+ - | vHOST0 | | vHOST1 | - +----------+ +-------------------------+ - | | | ^ ^ | - | | | | | | - | | (0)<----->(0) | ------ | | - | TG1 | | SUT | | - | | | (ovs-dpdk) | | - | | (n)<----->(n) |------------------ | - +----------+ +-------------------------+ - trafficgen_1 host - - -3-Node setup - Correlated Traffic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. code-block:: console - - +--------------------+ - | | - | | - | DUT | - | (VNF) | - | | - +--------------------+ - | virtio | | virtio | - +--------+ +--------+ - ^ ^ - | | - | | - +--------+ +--------+ - | vHOST0 | | vHOST1 | - +----------+ +-------------------------+ +------------+ - | | | ^ ^ | | | - | | | | | | | | - | | (0)<----->(0) | ------ | | | TG2 | - | TG1 | | SUT | | |(UDP Replay)| - | | | (ovs-dpdk) | | | | - | | (n)<----->(n) | ------ |(n)<-->(n)| | - +----------+ +-------------------------+ +------------+ - trafficgen_1 host trafficgen_2 - - -Before executing Yardstick test cases, make sure that pod.yaml reflects the -topology and update all the required fields.:: - - cp /etc/yardstick/nodes/pod.yaml.nsb.ovs.sample /etc/yardstick/nodes/pod.yaml - -Config pod.yaml -:: - nodes: - - - name: trafficgen_1 - role: TrafficGen - ip: 1.1.1.1 - user: root - password: r00t - interfaces: - xe0: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:07:00.0" - driver: i40e # default kernel driver - dpdk_port_num: 0 - local_ip: "152.16.100.20" - netmask: "255.255.255.0" - local_mac: "00:00:00:00:00:01" - xe1: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:07:00.1" - driver: i40e # default kernel driver - dpdk_port_num: 1 - local_ip: "152.16.40.20" - netmask: "255.255.255.0" - local_mac: "00:00.00:00:00:02" - -- - name: ovs - role: Ovsdpdk - ip: 2.2.2.2 - user: root - auth_type: password - password: <password> - vpath: "/usr/local/" - vports: - - dpdkvhostuser0 - - dpdkvhostuser1 - vports_mac: - - "00:00:00:00:00:03" - - "00:00:00:00:00:04" - phy_ports: # Physical ports to configure ovs - - "0000:06:00.0" - - "0000:06:00.1" - flow: - - ovs-ofctl add-flow br0 in_port=1,action=output:3 - - ovs-ofctl add-flow br0 in_port=3,action=output:1 - - ovs-ofctl add-flow br0 in_port=4,action=output:2 - - ovs-ofctl add-flow br0 in_port=2,action=output:4 - phy_driver: i40e # kernel driver - images: "/var/lib/libvirt/images/ubuntu1.img" - - - - name: vnf - role: vnf - ip: 1.1.1.2 - user: root - password: r00t - host: 2.2.2.2 #BM - host == ip, virtualized env - Host - compute node - interfaces: - xe0: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:00:04.0" - driver: virtio-pci # default kernel driver - dpdk_port_num: 0 - local_ip: "152.16.100.10" - netmask: "255.255.255.0" - local_mac: "00:00:00:00:00:03" - - xe1: # logical name from topology.yaml and vnfd.yaml - vpci: "0000:00:05.0" - driver: virtio-pci # default kernel driver - dpdk_port_num: 1 - local_ip: "152.16.40.10" - netmask: "255.255.255.0" - local_mac: "00:00:00:00:00:04" - routing_table: - - network: "152.16.100.10" - netmask: "255.255.255.0" - gateway: "152.16.100.20" - if: "xe0" - - network: "152.16.40.10" - netmask: "255.255.255.0" - gateway: "152.16.40.20" - if: "xe1" - nd_route_tbl: - - network: "0064:ff9b:0:0:0:0:9810:6414" - netmask: "112" - gateway: "0064:ff9b:0:0:0:0:9810:6414" - if: "xe0" - - network: "0064:ff9b:0:0:0:0:9810:2814" - netmask: "112" - gateway: "0064:ff9b:0:0:0:0:9810:2814" - if: "xe1" - -Enable yardstick virtual environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Before executing yardstick test cases, make sure to activate yardstick -python virtual environment if runnin on ubuntu without docker:: - - source /opt/nsb_bin/yardstick_venv/bin/activate - -On docker, virtual env is in main path. - -Run Yardstick - Network Service Testcases ------------------------------------------ - -NS testing - using NSBperf CLI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - PYTHONPATH: ". ~/.bash_profile" - cd <yardstick_repo>/yardstick/cmd - - Execute command: ./NSPerf.py -h - ./NSBperf.py --vnf <selected vnf> --test <rfc test> - eg: ./NSBperf.py --vnf vfw --test tc_ovs_rfc2544_ipv4_1flow_64B.yaml - -NS testing - using yardstick CLI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - PYTHONPATH: ". ~/.bash_profile" - -Go to test case forlder type we want to execute. - e.g. <yardstick repo>/samples/vnf_samples/nsut/<vnf>/ - run: yardstick --debug task start <test_case.yaml> diff --git a/docs/testing/user/userguide/15-list-of-tcs.rst b/docs/testing/user/userguide/15-list-of-tcs.rst index 1b5806cd9..b62bf6390 100644 --- a/docs/testing/user/userguide/15-list-of-tcs.rst +++ b/docs/testing/user/userguide/15-list-of-tcs.rst @@ -50,8 +50,14 @@ Generic NFVI Test Case Descriptions opnfv_yardstick_tc071.rst opnfv_yardstick_tc072.rst opnfv_yardstick_tc073.rst + opnfv_yardstick_tc074.rst opnfv_yardstick_tc075.rst opnfv_yardstick_tc076.rst + opnfv_yardstick_tc078.rst + opnfv_yardstick_tc079.rst + opnfv_yardstick_tc080.rst + opnfv_yardstick_tc081.rst + opnfv_yardstick_tc083.rst OPNFV Feature Test Cases ======================== diff --git a/docs/testing/user/userguide/index.rst b/docs/testing/user/userguide/index.rst index 3b55b7f9b..61e157e52 100644 --- a/docs/testing/user/userguide/index.rst +++ b/docs/testing/user/userguide/index.rst @@ -5,9 +5,9 @@ .. http://creativecommons.org/licenses/by/4.0 .. (c) OPNFV, Ericsson AB and others. -=========================================== -Performance Testing User Guide (Yardstick) -=========================================== +******************** +Yardstick User Guide +******************** .. toctree:: :maxdepth: 4 @@ -23,8 +23,10 @@ Performance Testing User Guide (Yardstick) 08-api 09-yardstick_user_interface 10-vtc-overview - 13-nsb-overview - 14-nsb_installation + 11-nsb-overview + 12-nsb_installation + 13-nsb_operation 15-list-of-tcs + nsb/nsb-list-of-tcs glossary references diff --git a/docs/testing/user/userguide/nsb/nsb-list-of-tcs.rst b/docs/testing/user/userguide/nsb/nsb-list-of-tcs.rst new file mode 100644 index 000000000..895837283 --- /dev/null +++ b/docs/testing/user/userguide/nsb/nsb-list-of-tcs.rst @@ -0,0 +1,30 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +===================== +NSB Sample Test Cases +===================== + +Abstract +======== + +This chapter lists available NSB test cases. + +NSB PROX Test Case Descriptions +=============================== + +.. toctree:: + :maxdepth: 1 + + tc_prox_context_acl_port + tc_prox_context_bng_port + tc_prox_context_bng_qos_port + tc_prox_context_l2fwd_port + tc_prox_context_l3fwd_port + tc_prox_context_mpls_tagging_port + tc_prox_context_buffering_port + tc_prox_context_load_balancer_port + tc_prox_context_vpe_port + tc_prox_context_lw_after_port diff --git a/docs/testing/user/userguide/nsb/tc_prox_context_acl_port.rst b/docs/testing/user/userguide/nsb/tc_prox_context_acl_port.rst new file mode 100644 index 000000000..137486151 --- /dev/null +++ b/docs/testing/user/userguide/nsb/tc_prox_context_acl_port.rst @@ -0,0 +1,112 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +********************************************* +Yardstick Test Case Description: NSB PROX ACL +********************************************* + ++-----------------------------------------------------------------------------+ +|NSB PROX test for NFVI characterization | +| | ++--------------+--------------------------------------------------------------+ +|test case id | tc_prox_{context}_acl-{port_num} | +| | | +| | * context = baremetal or heat_context; | +| | * port_num = 2 or 4; | +| | | ++--------------+--------------------------------------------------------------+ +|metric | * Network Throughput; | +| | * TG Packets Out; | +| | * TG Packets In; | +| | * VNF Packets Out; | +| | * VNF Packets In; | +| | * Dropped packets; | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | This test allows to measure how well the SUT can exploit | +| | structures in the list of ACL rules. | +| | The ACL rules are matched against a 7-tuple of the input | +| | packet: the regular 5-tuple and two VLAN tags. | +| | The rules in the rule set allow the packet to be forwarded | +| | and the rule set contains a default "match all" rule. | +| | | +| | The KPI is measured with the rule set that has a moderate | +| | number of rules with moderate similarity between the rules & | +| | the fraction of rules that were used. | +| | | +| | The ACL test cases are implemented to run in baremetal | +| | and heat context for 2 port and 4 port configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | The ACL test cases are listed below: | +| | | +| | * tc_prox_baremetal_acl-2.yaml | +| | * tc_prox_baremetal_acl-4.yaml | +| | * tc_prox_heat_context_acl-2.yaml | +| | * tc_prox_heat_context_acl-4.yaml | +| | | +| | Test duration is set as 300sec for each test. | +| | Packet size set as 64 bytes in traffic profile. | +| | These can be configured | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | PROX | +| | PROX is a DPDK application that can simulate VNF workloads | +| | and can generate traffic and used for NFVI characterization | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | This PROX ACL test cases can be configured with different: | +| | | +| | * packet sizes; | +| | * test durations; | +| | * tolerated loss; | +| | | +| | Default values exist. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | For Openstack test case image (yardstick-samplevnfs) needs | +|conditions | to be installed into Glance with Prox and Dpdk included in | +| | it. The test need multi-queue enabled in Glance image. | +| | | +| | For Baremetal tests cases Prox and Dpdk must be installed in | +| | the hosts where the test is executed. The pod.yaml file must | +| | have the necessary system and NIC information | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | For Baremetal test: The TG and VNF are started on the hosts | +| | based on the pod file. | +| | | +| | For Heat test: Two host VMs are booted, as Traffic generator | +| | and VNF(ACL workload) based on the test flavor. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the TG and VNF by using ssh. | +| | The test will resolve the topology and instantiate the VNF | +| | and TG and collect the KPI's/metrics. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | The TG will send packets to the VNF. If the number of | +| | dropped packets is more than the tolerated loss the line | +| | rate or throughput is halved. This is done until the dropped | +| | packets are within an acceptable tolerated loss. | +| | | +| | The KPI is the number of packets per second for 64 bytes | +| | packet size with an accepted minimal packet loss for the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | In Baremetal test: The test quits the application and unbind | +| | the dpdk ports. | +| | | +| | In Heat test: Two host VMs are deleted on test completion. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | The test case will achieve a Throughput with an accepted | +| | minimal tolerated packet loss. | ++--------------+--------------------------------------------------------------+ + diff --git a/docs/testing/user/userguide/nsb/tc_prox_context_bng_port.rst b/docs/testing/user/userguide/nsb/tc_prox_context_bng_port.rst new file mode 100644 index 000000000..b674846ff --- /dev/null +++ b/docs/testing/user/userguide/nsb/tc_prox_context_bng_port.rst @@ -0,0 +1,109 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +********************************************* +Yardstick Test Case Description: NSB PROX BNG +********************************************* + ++-----------------------------------------------------------------------------+ +|NSB PROX test for NFVI characterization | +| | ++--------------+--------------------------------------------------------------+ +|test case id | tc_prox_{context}_bng-{port_num} | +| | | +| | * context = baremetal or heat_context; | +| | * port_num = 4; | +| | | ++--------------+--------------------------------------------------------------+ +|metric | * Network Throughput; | +| | * TG Packets Out; | +| | * TG Packets In; | +| | * VNF Packets Out; | +| | * VNF Packets In; | +| | * Dropped packets; | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The BNG workload converts packets from QinQ to GRE tunnels, | +| | handles routing and adds/removes MPLS tags. | +| | This use case simulates a realistic and complex application. | +| | The number of users is 32K per port and the number of routes | +| | is 8K. | +| | | +| | The BNG test cases are implemented to run in baremetal | +| | and heat context an require 4 port topology to run the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | The BNG test cases are listed below: | +| | | +| | * tc_prox_baremetal_bng-2.yaml | +| | * tc_prox_baremetal_bng-4.yaml | +| | * tc_prox_heat_context_bng-2.yaml | +| | * tc_prox_heat_context_bng-4.yaml | +| | | +| | Test duration is set as 300sec for each test. | +| | The minimum packet size for BNG test is 78 bytes. This is | +| | set in the BNG traffic profile and can be configured to use | +| | a higher packet size for the test. | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | PROX | +| | PROX is a DPDK application that can simulate VNF workloads | +| | and can generate traffic and used for NFVI characterization | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | The PROX BNG test cases can be configured with different: | +| | | +| | * packet sizes; | +| | * test durations; | +| | * tolerated loss; | +| | | +| | Default values exist. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | For Openstack test case image (yardstick-samplevnfs) needs | +|conditions | to be installed into Glance with Prox and Dpdk included in | +| | it. The test need multi-queue enabled in Glance image. | +| | | +| | For Baremetal tests cases Prox and Dpdk must be installed in | +| | the hosts where the test is executed. The pod.yaml file must | +| | have the necessary system and NIC information | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | For Baremetal test: The TG and VNF are started on the hosts | +| | based on the pod file. | +| | | +| | For Heat test: Two host VMs are booted, as Traffic generator | +| | and VNF(BNG workload) based on the test flavor. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the TG and VNF by using ssh. | +| | The test will resolve the topology and instantiate the VNF | +| | and TG and collect the KPI's/metrics. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | The TG will send packets to the VNF. If the number of | +| | dropped packets is more than the tolerated loss the line | +| | rate or throughput is halved. This is done until the dropped | +| | packets are within an acceptable tolerated loss. | +| | | +| | The KPI is the number of packets per second for 78 bytes | +| | packet size with an accepted minimal packet loss for the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | In Baremetal test: The test quits the application and unbind | +| | the dpdk ports. | +| | | +| | In Heat test: Two host VMs are deleted on test completion. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | The test case will achieve a Throughput with an accepted | +| | minimal tolerated packet loss. | ++--------------+--------------------------------------------------------------+ + diff --git a/docs/testing/user/userguide/nsb/tc_prox_context_bng_qos_port.rst b/docs/testing/user/userguide/nsb/tc_prox_context_bng_qos_port.rst new file mode 100644 index 000000000..5270634ac --- /dev/null +++ b/docs/testing/user/userguide/nsb/tc_prox_context_bng_qos_port.rst @@ -0,0 +1,111 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +************************************************* +Yardstick Test Case Description: NSB PROX BNG_QoS +************************************************* + ++-----------------------------------------------------------------------------+ +|NSB PROX test for NFVI characterization | +| | ++--------------+--------------------------------------------------------------+ +|test case id | tc_prox_{context}_bng_qos-{port_num} | +| | | +| | * context = baremetal or heat_context; | +| | * port_num = 4; | +| | | ++--------------+--------------------------------------------------------------+ +|metric | * Network Throughput; | +| | * TG Packets Out; | +| | * TG Packets In; | +| | * VNF Packets Out; | +| | * VNF Packets In; | +| | * Dropped packets; | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The BNG+QoS workload converts packets from QinQ to GRE | +| | tunnels, handles routing and adds/removes MPLS tags and | +| | performs a QoS. | +| | This use case simulates a realistic and complex application. | +| | The number of users is 32K per port and the number of routes | +| | is 8K. | +| | | +| | The BNG_QoS test cases are implemented to run in baremetal | +| | and heat context an require 4 port topology to run the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | The BNG_QoS test cases are listed below: | +| | | +| | * tc_prox_baremetal_bng_qos-2.yaml | +| | * tc_prox_baremetal_bng_qos-4.yaml | +| | * tc_prox_heat_context_bng_qos-2.yaml | +| | * tc_prox_heat_context_bng_qos-4.yaml | +| | | +| | Test duration is set as 300sec for each test. | +| | The minumum packet size for BNG_QoS test is 78 bytes. This | +| | is set in the bng_qos traffic profile and can be configured | +| | to use a higher packet size for the test. | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | PROX | +| | PROX is a DPDK application that can simulate VNF workloads | +| | and can generate traffic and used for NFVI characterization | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | This PROX BNG_QoS test cases can be configured with | +| | different: | +| | | +| | * packet sizes; | +| | * test durations; | +| | * tolerated loss; | +| | | +| | Default values exist. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | For Openstack test case image (yardstick-samplevnfs) needs | +|conditions | to be installed into Glance with Prox and Dpdk included in | +| | it. The test need multi-queue enabled in Glance image. | +| | | +| | For Baremetal tests cases Prox and Dpdk must be installed in | +| | the hosts where the test is executed. The pod.yaml file must | +| | have the necessary system and NIC information | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | For Baremetal test: The TG and VNF are started on the hosts | +| | based on the pod file. | +| | | +| | For Heat test: Two host VMs are booted, as Traffic generator | +| | and VNF(BNG_QoS workload) based on the test flavor. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the TG and VNF by using ssh. | +| | The test will resolve the topology and instantiate the VNF | +| | and TG and collect the KPI's/metrics. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | The TG will send packets to the VNF. If the number of | +| | dropped packets is more than the tolerated loss the line | +| | rate or throughput is halved. This is done until the dropped | +| | packets are within an acceptable tolerated loss. | +| | | +| | The KPI is the number of packets per second for 78 bytes | +| | packet size with an accepted minimal packet loss for the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | In Baremetal test: The test quits the application and unbind | +| | the dpdk ports. | +| | | +| | In Heat test: Two host VMs are deleted on test completion. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | The test case will achieve a Throughput with an accepted | +| | minimal tolerated packet loss. | ++--------------+--------------------------------------------------------------+ + diff --git a/docs/testing/user/userguide/nsb/tc_prox_context_buffering_port.rst b/docs/testing/user/userguide/nsb/tc_prox_context_buffering_port.rst new file mode 100644 index 000000000..0ab242cf2 --- /dev/null +++ b/docs/testing/user/userguide/nsb/tc_prox_context_buffering_port.rst @@ -0,0 +1,107 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +********************************************************** +Yardstick Test Case Description: NSB PROX Packet Buffering +********************************************************** + ++-----------------------------------------------------------------------------+ +|NSB PROX test for NFVI characterization | +| | ++--------------+--------------------------------------------------------------+ +|test case id | tc_prox_{context}_buffering-{port_num} | +| | | +| | * context = baremetal or heat_context | +| | * port_num = 1 | +| | | ++--------------+--------------------------------------------------------------+ +|metric | * Network Throughput; | +| | * TG Packets Out; | +| | * TG Packets In; | +| | * VNF Packets Out; | +| | * VNF Packets In; | +| | * Dropped packets; | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | This test measures the impact of the condition when packets | +| | get buffered, thus they stay in memory for the extended | +| | period of time, 125ms in this case. | +| | | +| | The Packet Buffering test cases are implemented to run in | +| | baremetal and heat context. | +| | | +| | The test runs only on the first port of the SUT. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | The Packet Buffering test cases are listed below: | +| | | +| | * tc_prox_baremetal_buffering-1.yaml | +| | * tc_prox_heat_context_buffering-1.yaml | +| | | +| | Test duration is set as 300sec for each test. | +| | The minimum packet size for Buffering test is 64 bytes. This | +| | is set in the traffic profile and can be configured to use | +| | a higher packet size for the test. | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | PROX | +| | PROX is a DPDK application that can simulate VNF workloads | +| | and can generate traffic and used for NFVI characterization | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | The PROX Packet Buffering test cases can be configured with | +| | different: | +| | | +| | * packet sizes; | +| | * test durations; | +| | * tolerated loss; | +| | | +| | Default values exist. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | For Openstack test case image (yardstick-samplevnfs) needs | +|conditions | to be installed into Glance with Prox and Dpdk included in | +| | it. The test need multi-queue enabled in Glance image. | +| | | +| | For Baremetal tests cases Prox and Dpdk must be installed in | +| | the hosts where the test is executed. The pod.yaml file must | +| | have the necessary system and NIC information | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | For Baremetal test: The TG and VNF are started on the hosts | +| | based on the pod file. | +| | | +| | For Heat test: Two host VMs are booted, as Traffic generator | +| | and VNF(Packet Buffering workload) based on the test flavor. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the TG and VNF by using ssh. | +| | The test will resolve the topology and instantiate the VNF | +| | and TG and collect the KPI's/metrics. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | The TG will send packets to the VNF. If the number of | +| | dropped packets is more than the tolerated loss the line | +| | rate or throughput is halved. This is done until the dropped | +| | packets are within an acceptable tolerated loss. | +| | | +| | The KPI in this test is the maximum number of packets that | +| | can be forwarded given the requirement that the latency of | +| | each packet is at least 125 millisecond. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | In Baremetal test: The test quits the application and unbind | +| | the dpdk ports. | +| | | +| | In Heat test: Two host VMs are deleted on test completion. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | The test case will achieve a Throughput with an accepted | +| | minimal tolerated packet loss. | ++--------------+--------------------------------------------------------------+ + diff --git a/docs/testing/user/userguide/nsb/tc_prox_context_l2fwd_port.rst b/docs/testing/user/userguide/nsb/tc_prox_context_l2fwd_port.rst new file mode 100644 index 000000000..82cb64fe5 --- /dev/null +++ b/docs/testing/user/userguide/nsb/tc_prox_context_l2fwd_port.rst @@ -0,0 +1,120 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +*********************************************** +Yardstick Test Case Description: NSB PROX L2FWD +*********************************************** + ++-----------------------------------------------------------------------------+ +|NSB PROX test for NFVI characterization | +| | ++--------------+--------------------------------------------------------------+ +|test case id | tc_prox_{context}_l2fwd-{port_num} | +| | | +| | * context = baremetal or heat_context; | +| | * port_num = 2 or 4; | +| | | ++--------------+--------------------------------------------------------------+ +|metric | * Network Throughput; | +| | * TG Packets Out; | +| | * TG Packets In; | +| | * VNF Packets Out; | +| | * VNF Packets In; | +| | * Dropped packets; | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The PROX L2FWD test has 3 types of test cases: | +| | L2FWD: The application will take packets in from one port | +| | and forward them unmodified to another port | +| | L2FWD_Packet_Touch: The application will take packets in | +| | from one port, update src and dst MACs and forward them to | +| | another port. | +| | L2FWD_Multi_Flow: The application will take packets in | +| | from one port, update src and dst MACs and forward them to | +| | another port. This test case exercises the softswitch | +| | with 200k flows. | +| | | +| | The above test cases are implemented for baremetal and heat | +| | context for 2 port and 4 port configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | The L2FWD test cases are listed below: | +| | | +| | * tc_prox_baremetal_l2fwd-2.yaml | +| | * tc_prox_baremetal_l2fwd-4.yaml | +| | * tc_prox_baremetal_l2fwd_pktTouch-2.yaml | +| | * tc_prox_baremetal_l2fwd_pktTouch-4.yaml | +| | * tc_prox_baremetal_l2fwd_multiflow-2.yaml | +| | * tc_prox_baremetal_l2fwd_multiflow-4.yaml | +| | * tc_prox_heat_context_l2fwd-2.yaml | +| | * tc_prox_heat_context_l2fwd-4.yaml | +| | * tc_prox_heat_context_l2fwd_pktTouch-2.yaml | +| | * tc_prox_heat_context_l2fwd_pktTouch-4.yaml | +| | * tc_prox_heat_context_l2fwd_multiflow-2.yaml | +| | * tc_prox_heat_context_l2fwd_multiflow-4.yaml | +| | | +| | Test duration is set as 300sec for each test. | +| | Packet size set as 64 bytes in traffic profile | +| | These can be configured | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | PROX | +| | PROX is a DPDK application that can simulate VNF workloads | +| | and can generate traffic and used for NFVI characterization | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | The PROX L2FWD test cases can be configured with different: | +| | | +| | * packet sizes; | +| | * test durations; | +| | * tolerated loss; | +| | | +| | Default values exist. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | For Openstack test case image (yardstick-samplevnfs) needs | +|conditions | to be installed into Glance with Prox and Dpdk included in | +| | it. | +| | | +| | For Baremetal tests cases Prox and Dpdk must be installed in | +| | the hosts where the test is executed. The pod.yaml file must | +| | have the necessary system and NIC information | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | For Baremetal test: The TG and VNF are started on the hosts | +| | based on the pod file. | +| | | +| | For Heat test: Two host VMs are booted, as Traffic generator | +| | and VNF(L2FWD workload) based on the test flavor. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the TG and VNF by using ssh. | +| | The test will resolve the topology and instantiate the VNF | +| | and TG and collect the KPI's/metrics. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | The TG will send packets to the VNF. If the number of | +| | dropped packets is more than the tolerated loss the line | +| | rate or throughput is halved. This is done until the dropped | +| | packets are within an acceptable tolerated loss. | +| | | +| | The KPI is the number of packets per second for 64 bytes | +| | packet size with an accepted minimal packet loss for the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | In Baremetal test: The test quits the application and unbind | +| | the dpdk ports. | +| | | +| | In Heat test: Two host VMs are deleted on test completion. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | The test case will achieve a Throughput with an accepted | +| | minimal tolerated packet loss. | ++--------------+--------------------------------------------------------------+ + diff --git a/docs/testing/user/userguide/nsb/tc_prox_context_l3fwd_port.rst b/docs/testing/user/userguide/nsb/tc_prox_context_l3fwd_port.rst new file mode 100644 index 000000000..87cc10360 --- /dev/null +++ b/docs/testing/user/userguide/nsb/tc_prox_context_l3fwd_port.rst @@ -0,0 +1,105 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +*********************************************** +Yardstick Test Case Description: NSB PROX L3FWD +*********************************************** + ++-----------------------------------------------------------------------------+ +|NSB PROX test for NFVI characterization | +| | ++--------------+--------------------------------------------------------------+ +|test case id | tc_prox_{context}_l3fwd-{port_num} | +| | | +| | * context = baremetal or heat_context; | +| | * port_num = 2 or 4; | +| | | ++--------------+--------------------------------------------------------------+ +|metric | * Network Throughput; | +| | * TG Packets Out; | +| | * TG Packets In; | +| | * VNF Packets Out; | +| | * VNF Packets In; | +| | * Dropped packets; | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The PROX L3FWD application performs basic routing of packets | +| | with LPM based look-up method. | +| | | +| | The L3FWD test cases are implemented for baremetal and heat | +| | context for 2 port and 4 port configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | The L3FWD test cases are listed below: | +| | | +| | * tc_prox_baremetal_l3fwd-2.yaml | +| | * tc_prox_baremetal_l3fwd-4.yaml | +| | * tc_prox_heat_context_l3fwd-2.yaml | +| | * tc_prox_heat_context_l3fwd-4.yaml | +| | | +| | Test duration is set as 300sec for each test. | +| | The minimum packet size for L3FWD test is 64 bytes. This is | +| | set in the traffic profile and can be configured to use | +| | a higher packet size for the test. | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | PROX | +| | PROX is a DPDK application that can simulate VNF workloads | +| | and can generate traffic and used for NFVI characterization | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | This PROX L3FWD test cases can be configured with different: | +| | | +| | * packet sizes; | +| | * test durations; | +| | * tolerated loss; | +| | | +| | Default values exist. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | For Openstack test case image (yardstick-samplevnfs) needs | +|conditions | to be installed into Glance with Prox and Dpdk included in | +| | it. The test need multi-queue enabled in Glance image. | +| | | +| | For Baremetal tests cases Prox and Dpdk must be installed in | +| | the hosts where the test is executed. The pod.yaml file must | +| | have the necessary system and NIC information | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | For Baremetal test: The TG and VNF are started on the hosts | +| | based on the pod file. | +| | | +| | For Heat test: Two host VMs are booted, as Traffic generator | +| | and VNF(L3FWD workload) based on the test flavor. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the TG and VNF by using ssh. | +| | The test will resolve the topology and instantiate the VNF | +| | and TG and collect the KPI's/metrics. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | The TG will send packet to the VNF. If the number of dropped | +| | packets is more than the tolerated loss the line rate | +| | or throughput is halved. This is done until the dropped | +| | packets are within an acceptable tolerated loss. | +| | | +| | The KPI is the number of packets per second for 64 byte | +| | packets with an accepted minimal packet loss for the default | +| | configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | In Baremetal test: The test quits the application and unbind | +| | the dpdk ports. | +| | | +| | In Heat test: Two host VMs are deleted on test completion. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | The test case will achieve a Throughput with an accepted | +| | minimal tolerated packet loss. | ++--------------+--------------------------------------------------------------+ + diff --git a/docs/testing/user/userguide/nsb/tc_prox_context_load_balancer_port.rst b/docs/testing/user/userguide/nsb/tc_prox_context_load_balancer_port.rst new file mode 100644 index 000000000..ada02f829 --- /dev/null +++ b/docs/testing/user/userguide/nsb/tc_prox_context_load_balancer_port.rst @@ -0,0 +1,109 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +******************************************************* +Yardstick Test Case Description: NSB PROX Load Balancer +******************************************************* + ++-----------------------------------------------------------------------------+ +|NSB PROX test for NFVI characterization | +| | ++--------------+--------------------------------------------------------------+ +|test case id | tc_prox_{context}_lb-{port_num} | +| | | +| | * context = baremetal or heat_context | +| | * port_num = 4 | +| | | ++--------------+--------------------------------------------------------------+ +|metric | * Network Throughput; | +| | * TG Packets Out; | +| | * TG Packets In; | +| | * VNF Packets Out; | +| | * VNF Packets In; | +| | * Dropped packets; | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The applciation transmits packets on one port and revieves | +| | them on 4 ports. | +| | The conventional 5-tuple is used in this test as it requires | +| | some extraction steps and allows defining enough distinct | +| | values to find the performance limits. | +| | | +| | The load is increased (adding more ports if needed) while | +| | packets are load balanced using a hash table of 8M entries | +| | | +| | The number of packets per second that can be forwarded | +| | determines the KPI. The default packet size is 64 bytes. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | The Load Balancer test cases are listed below: | +| | | +| | * tc_prox_baremetal_lb-4.yaml | +| | * tc_prox_heat_context_lb-4.yaml | +| | | +| | Test duration is set as 300sec for each test. | +| | Packet size set as 64 bytes in traffic profile. | +| | These can be configured | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | PROX | +| | PROX is a DPDK application that can simulate VNF workloads | +| | and can generate traffic and used for NFVI characterization | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | The PROX Load Balancer test cases can be configured with | +| | different: | +| | | +| | * packet sizes; | +| | * test durations; | +| | * tolerated loss; | +| | | +| | Default values exist. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | For Openstack test case image (yardstick-samplevnfs) needs | +|conditions | to be installed into Glance with Prox and Dpdk included in | +| | it. The test need multi-queue enabled in Glance image. | +| | | +| | For Baremetal tests cases Prox and Dpdk must be installed in | +| | the hosts where the test is executed. The pod.yaml file must | +| | have the necessary system and NIC information | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | For Baremetal test: The TG and VNF are started on the hosts | +| | based on the pod file. | +| | | +| | For Heat test: Two host VMs are booted, as Traffic generator | +| | and VNF(Load Balancer workload) based on the test flavor. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the TG and VNF by using ssh. | +| | The test will resolve the topology and instantiate the VNF | +| | and TG and collect the KPI's/metrics. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | The TG will send packets to the VNF. If the number of | +| | dropped packets is more than the tolerated loss the line | +| | rate or throughput is halved. This is done until the dropped | +| | packets are within an acceptable tolerated loss. | +| | | +| | The KPI is the number of packets per second for 78 bytes | +| | packet size with an accepted minimal packet loss for the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | In Baremetal test: The test quits the application and unbind | +| | the dpdk ports. | +| | | +| | In Heat test: Two host VMs are deleted on test completion. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | The test case will achieve a Throughput with an accepted | +| | minimal tolerated packet loss. | ++--------------+--------------------------------------------------------------+ + diff --git a/docs/testing/user/userguide/nsb/tc_prox_context_lw_aftr_port.rst b/docs/testing/user/userguide/nsb/tc_prox_context_lw_aftr_port.rst new file mode 100644 index 000000000..5a1fada05 --- /dev/null +++ b/docs/testing/user/userguide/nsb/tc_prox_context_lw_aftr_port.rst @@ -0,0 +1,107 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +************************************************ +Yardstick Test Case Description: NSB PROX LwAFTR +************************************************ + ++-----------------------------------------------------------------------------+ +|NSB PROX test for NFVI characterization | +| | ++--------------+--------------------------------------------------------------+ +|test case id | tc_prox_{context}_lw_aftr-{port_num} | +| | | +| | * context = baremetal or heat_context; | +| | * port_num = 4; | +| | | ++--------------+--------------------------------------------------------------+ +|metric | * Network Throughput; | +| | * TG Packets Out; | +| | * TG Packets In; | +| | * VNF Packets Out; | +| | * VNF Packets In; | +| | * Dropped packets; | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The PROX LW_AFTR test will take packets in from one | +| | port and remove the ipv6 encapsulation and forward them to | +| | another port. While forwarded packets in other direction | +| | will be encapsulated in an ipv6 header. | +| | | +| | The lw_aftr test cases are implemented to run in baremetal | +| | and heat context an require 4 port topology to run the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | The LW_AFTR test cases are listed below: | +| | | +| | * tc_prox_baremetal_lw_aftr-4.yaml | +| | * tc_prox_heat_context_lw_aftr-4.yaml | +| | | +| | Test duration is set as 300sec for each test. | +| | The minimum packet size for MPLS test is 68 bytes. This is | +| | set in the traffic profile and can be configured to use | +| | higher packet sizes. | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | PROX | +| | PROX is a DPDK application that can simulate VNF workloads | +| | and can generate traffic and used for NFVI characterization | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | The PROX lwAFTR test cases can be configured with | +| | different: | +| | | +| | * packet sizes; | +| | * test durations; | +| | * tolerated loss; | +| | | +| | Default values exist. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | For Openstack test case image (yardstick-samplevnfs) needs | +|conditions | to be installed into Glance with Prox and Dpdk included in | +| | it. | +| | | +| | For Baremetal tests cases Prox and Dpdk must be installed in | +| | the hosts where the test is executed. The pod.yaml file must | +| | have the necessary system and NIC information | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | For Baremetal test: The TG and VNF are started on the hosts | +| | based on the pod file. | +| | | +| | For Heat test: Two host VMs are booted, as Traffic generator | +| | and VNF(LW_AFTR workload) based on the test flavor. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the TG and VNF by using ssh. | +| | The test will resolve the topology and instantiate the VNF | +| | and TG and collect the KPI's/metrics. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | The TG will send packets to the VNF. If the number of | +| | dropped packets is more than the tolerated loss the line | +| | rate or throughput is halved. This is done until the dropped | +| | packets are within an acceptable tolerated loss. | +| | | +| | The KPI is the number of packets per second for 86 bytes | +| | packet size with an accepted minimal packet loss for the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | In Baremetal test: The test quits the application and unbind | +| | the dpdk ports. | +| | | +| | In Heat test: Two host VMs are deleted on test completion. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | The test case will achieve a Throughput with an accepted | +| | minimal tolerated packet loss. | ++--------------+--------------------------------------------------------------+ + diff --git a/docs/testing/user/userguide/nsb/tc_prox_context_mpls_tagging_port.rst b/docs/testing/user/userguide/nsb/tc_prox_context_mpls_tagging_port.rst new file mode 100644 index 000000000..cef859996 --- /dev/null +++ b/docs/testing/user/userguide/nsb/tc_prox_context_mpls_tagging_port.rst @@ -0,0 +1,109 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +****************************************************** +Yardstick Test Case Description: NSB PROX MPLS Tagging +****************************************************** + ++-----------------------------------------------------------------------------+ +|NSB PROX test for NFVI characterization | +| | ++--------------+--------------------------------------------------------------+ +|test case id | tc_prox_{context}_mpls_tagging-{port_num} | +| | | +| | * context = baremetal or heat_context; | +| | * port_num = 2 or 4; | +| | | ++--------------+--------------------------------------------------------------+ +|metric | * Network Throughput; | +| | * TG Packets Out; | +| | * TG Packets In; | +| | * VNF Packets Out; | +| | * VNF Packets In; | +| | * Dropped packets; | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The PROX MPLS Tagging test will take packets in from one | +| | port add an MPLS tag and forward them to another port. | +| | While forwarding packets in other direction MPLS tags will | +| | be removed. | +| | | +| | The MPLS test cases are implemented to run in baremetal | +| | and heat context an require 4 port topology to run the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | The MPLS Tagging test cases are listed below: | +| | | +| | * tc_prox_baremetal_mpls_tagging-2.yaml | +| | * tc_prox_baremetal_mpls_tagging-4.yaml | +| | * tc_prox_heat_context_mpls_tagging-2.yaml | +| | * tc_prox_heat_context_mpls_tagging-4.yaml | +| | | +| | Test duration is set as 300sec for each test. | +| | The minimum packet size for MPLS test is 68 bytes. This is | +| | set in the traffic profile and can be configured to use | +| | higher packet sizes. | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | PROX | +| | PROX is a DPDK application that can simulate VNF workloads | +| | and can generate traffic and used for NFVI characterization | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | The PROX MPLS Tagging test cases can be configured with | +| | different: | +| | | +| | * packet sizes; | +| | * test durations; | +| | * tolerated loss; | +| | | +| | Default values exist. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | For Openstack test case image (yardstick-samplevnfs) needs | +|conditions | to be installed into Glance with Prox and Dpdk included in | +| | it. | +| | | +| | For Baremetal tests cases Prox and Dpdk must be installed in | +| | the hosts where the test is executed. The pod.yaml file must | +| | have the necessary system and NIC information | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | For Baremetal test: The TG and VNF are started on the hosts | +| | based on the pod file. | +| | | +| | For Heat test: Two host VMs are booted, as Traffic generator | +| | and VNF(MPLS workload) based on the test flavor. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the TG and VNF by using ssh. | +| | The test will resolve the topology and instantiate the VNF | +| | and TG and collect the KPI's/metrics. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | The TG will send packets to the VNF. If the number of | +| | dropped packets is more than the tolerated loss the line | +| | rate or throughput is halved. This is done until the dropped | +| | packets are within an acceptable tolerated loss. | +| | | +| | The KPI is the number of packets per second for 68 bytes | +| | packet size with an accepted minimal packet loss for the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | In Baremetal test: The test quits the application and unbind | +| | the dpdk ports. | +| | | +| | In Heat test: Two host VMs are deleted on test completion. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | The test case will achieve a Throughput with an accepted | +| | minimal tolerated packet loss. | ++--------------+--------------------------------------------------------------+ + diff --git a/docs/testing/user/userguide/nsb/tc_prox_context_vpe_port.rst b/docs/testing/user/userguide/nsb/tc_prox_context_vpe_port.rst new file mode 100644 index 000000000..6827b0525 --- /dev/null +++ b/docs/testing/user/userguide/nsb/tc_prox_context_vpe_port.rst @@ -0,0 +1,108 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, 2017 Intel Corporation. + +********************************************** +Yardstick Test Case Description: NSB PROXi VPE +********************************************** + ++-----------------------------------------------------------------------------+ +|NSB PROX test for NFVI characterization | +| | ++--------------+--------------------------------------------------------------+ +|test case id | tc_prox_{context}_vpe-{port_num} | +| | | +| | * context = baremetal or heat_context; | +| | * port_num = 4; | +| | | ++--------------+--------------------------------------------------------------+ +|metric | * Network Throughput; | +| | * TG Packets Out; | +| | * TG Packets In; | +| | * VNF Packets Out; | +| | * VNF Packets In; | +| | * Dropped packets; | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The PROX VPE test handles packet processing, routing, QinQ | +| | encapsulation, flows, ACL rules, adds/removes MPLS tagging | +| | and performs QoS before forwarding packet to another port. | +| | The reverse applies to forwarded packets in the other | +| | direction. | +| | | +| | The VPE test cases are implemented to run in baremetal | +| | and heat context an require 4 port topology to run the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | The VPE test cases are listed below: | +| | | +| | * tc_prox_baremetal_vpe-4.yaml | +| | * tc_prox_heat_context_vpe-4.yaml | +| | | +| | Test duration is set as 300sec for each test. | +| | The minimum packet size for VPE test is 68 bytes. This is | +| | set in the traffic profile and can be configured to use | +| | higher packet sizes. | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | PROX | +| | PROX is a DPDK application that can simulate VNF workloads | +| | and can generate traffic and used for NFVI characterization | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | The PROX VPE test cases can be configured with | +| | different: | +| | | +| | * packet sizes; | +| | * test durations; | +| | * tolerated loss; | +| | | +| | Default values exist. | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | For Openstack test case image (yardstick-samplevnfs) needs | +|conditions | to be installed into Glance with Prox and Dpdk included in | +| | it. | +| | | +| | For Baremetal tests cases Prox and Dpdk must be installed in | +| | the hosts where the test is executed. The pod.yaml file must | +| | have the necessary system and NIC information | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | For Baremetal test: The TG and VNF are started on the hosts | +| | based on the pod file. | +| | | +| | For Heat test: Two host VMs are booted, as Traffic generator | +| | and VNF(VPE workload) based on the test flavor. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the TG and VNF by using ssh. | +| | The test will resolve the topology and instantiate the VNF | +| | and TG and collect the KPI's/metrics. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | The TG will send packets to the VNF. If the number of | +| | dropped packets is more than the tolerated loss the line | +| | rate or throughput is halved. This is done until the dropped | +| | packets are within an acceptable tolerated loss. | +| | | +| | The KPI is the number of packets per second for 68 bytes | +| | packet size with an accepted minimal packet loss for the | +| | default configuration. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | In Baremetal test: The test quits the application and unbind | +| | the dpdk ports. | +| | | +| | In Heat test: Two host VMs are deleted on test completion. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | The test case will achieve a Throughput with an accepted | +| | minimal tolerated packet loss. | ++--------------+--------------------------------------------------------------+ + diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc002.rst b/docs/testing/user/userguide/opnfv_yardstick_tc002.rst index c98780fd5..bf2466fb2 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc002.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc002.rst @@ -106,8 +106,8 @@ Yardstick Test Case Description TC002 | | | +--------------+--------------------------------------------------------------+ |step 2 | Yardstick is connected with the server VM by using ssh. | -| | 'ping_benchmark' bash script is copyied from Jump Host to | -| | the server VM via the ssh tunnel. | +| | 'ping_benchmark' bash script is copied from Jump Host to the | +| | server VM via the ssh tunnel. | | | | +--------------+--------------------------------------------------------------+ |step 3 | Ping is invoked. Ping packets are sent from server VM to | diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc078.rst b/docs/testing/user/userguide/opnfv_yardstick_tc078.rst index 560d55e07..b5a6545ba 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc078.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc078.rst @@ -114,7 +114,8 @@ Yardstick Test Case Description TC078 |step 3 | Yardstick is connected with the target server by using ssh. | | | If custom runspec config file is used, this file is copyied | | | from yardstick to the target server via the ssh tunnel. | ---------------+---------------------------------------------------------------+ +| | | ++--------------+--------------------------------------------------------------+ |step 4 | SPEC CPU2006 benchmark is invoked and SPEC CPU 2006 metrics | | | are generated. | | | | diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc080.rst b/docs/testing/user/userguide/opnfv_yardstick_tc080.rst new file mode 100644 index 000000000..05eca502e --- /dev/null +++ b/docs/testing/user/userguide/opnfv_yardstick_tc080.rst @@ -0,0 +1,117 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, Huawei Technologies Co.,Ltd and others. + +************************************* +Yardstick Test Case Description TC080 +************************************* + +.. _Ping: https://linux.die.net/man/8/ping + ++-----------------------------------------------------------------------------+ +|Network Latency | +| | ++--------------+--------------------------------------------------------------+ +|test case id | OPNFV_YARDSTICK_TC080_NETWORK_LATENCY_BETWEEN_CONTAINER | +| | | ++--------------+--------------------------------------------------------------+ +|metric | RTT (Round Trip Time) | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The purpose of TC080 is to do a basic verification that | +| | network latency is within acceptable boundaries when packets | +| | travel between containers located in two different | +| | Kubernetes pods. | +| | | +| | The purpose is also to be able to spot the trends. | +| | Test results, graphs and similar shall be stored for | +| | comparison reasons and product evolution understanding | +| | between different OPNFV versions and/or configurations. | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | ping | +| | | +| | Ping is a computer network administration software utility | +| | used to test the reachability of a host on an Internet | +| | Protocol (IP) network. It measures the round-trip time for | +| | packet sent from the originating host to a destination | +| | computer that are echoed back to the source. | +| | | +| | Ping is normally part of any Linux distribution, hence it | +| | doesn't need to be installed. It is also part of the | +| | Yardstick Docker image. | +| | | ++--------------+--------------------------------------------------------------+ +|test topology | Ping packets (ICMP protocol's mandatory ECHO_REQUEST | +| | datagram) are sent from host container to target container | +| | to elicit ICMP ECHO_RESPONSE. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | file: opnfv_yardstick_tc080.yaml | +| | | +| | Packet size 200 bytes. Test duration 60 seconds. | +| | SLA RTT is set to maximum 10 ms. | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | This test case can be configured with different: | +| | | +| | * packet sizes; | +| | * burst sizes; | +| | * ping intervals; | +| | * test durations; | +| | * test iterations. | +| | | +| | Default values exist. | +| | | +| | SLA is optional. The SLA in this test case serves as an | +| | example. Considerably lower RTT is expected, and also normal | +| | to achieve in balanced L2 environments. However, to cover | +| | most configurations, both bare metal and fully virtualized | +| | ones, this value should be possible to achieve and | +| | acceptable for black box testing. Many real time | +| | applications start to suffer badly if the RTT time is higher | +| | than this. Some may suffer bad also close to this RTT, while | +| | others may not suffer at all. It is a compromise that may | +| | have to be tuned for different configuration purposes. | +| | | ++--------------+--------------------------------------------------------------+ +|usability | This test case should be run in Kunernetes environment. | +| | | ++--------------+--------------------------------------------------------------+ +|references | Ping_ | +| | | +| | ETSI-NFV-TST001 | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | The test case Docker image (openretriever/yardstick) needs | +|conditions | to be pulled into Kubernetes environment. | +| | | +| | No further requirements have been identified. | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | Two containers are booted, as server and client. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the server container by using | +| | ssh. 'ping_benchmark' bash script is copied from Jump Host | +| | to the server container via the ssh tunnel. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | Ping is invoked. Ping packets are sent from server container | +| | to client container. RTT results are calculated and checked | +| | against the SLA. Logs are produced and stored. | +| | | +| | Result: Logs are stored. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | Two containers are deleted. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | Test should not PASS if any RTT is above the optional SLA | +| | value, or if there is a test case execution problem. | +| | | ++--------------+--------------------------------------------------------------+ diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc081.rst b/docs/testing/user/userguide/opnfv_yardstick_tc081.rst new file mode 100644 index 000000000..90af8a382 --- /dev/null +++ b/docs/testing/user/userguide/opnfv_yardstick_tc081.rst @@ -0,0 +1,122 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, Huawei Technologies Co.,Ltd and others. + +************************************* +Yardstick Test Case Description TC080 +************************************* + +.. _cirros-image: https://download.cirros-cloud.net +.. _Ping: https://linux.die.net/man/8/ping + ++-----------------------------------------------------------------------------+ +|Network Latency | +| | ++--------------+--------------------------------------------------------------+ +|test case id | OPNFV_YARDSTICK_TC081_NETWORK_LATENCY_BETWEEN_CONTAINER_AND_ | +| | VM | +| | | ++--------------+--------------------------------------------------------------+ +|metric | RTT (Round Trip Time) | +| | | ++--------------+--------------------------------------------------------------+ +|test purpose | The purpose of TC080 is to do a basic verification that | +| | network latency is within acceptable boundaries when packets | +| | travel between a containers and a VM. | +| | | +| | The purpose is also to be able to spot the trends. | +| | Test results, graphs and similar shall be stored for | +| | comparison reasons and product evolution understanding | +| | between different OPNFV versions and/or configurations. | +| | | ++--------------+--------------------------------------------------------------+ +|test tool | ping | +| | | +| | Ping is a computer network administration software utility | +| | used to test the reachability of a host on an Internet | +| | Protocol (IP) network. It measures the round-trip time for | +| | packet sent from the originating host to a destination | +| | computer that are echoed back to the source. | +| | | +| | Ping is normally part of any Linux distribution, hence it | +| | doesn't need to be installed. It is also part of the | +| | Yardstick Docker image. (For example also a Cirros image can | +| | be downloaded from cirros-image_, it includes ping) | +| | | ++--------------+--------------------------------------------------------------+ +|test topology | Ping packets (ICMP protocol's mandatory ECHO_REQUEST | +| | datagram) are sent from host container to target vm to | +| | elicit ICMP ECHO_RESPONSE. | +| | | ++--------------+--------------------------------------------------------------+ +|configuration | file: opnfv_yardstick_tc081.yaml | +| | | +| | Packet size 200 bytes. Test duration 60 seconds. | +| | SLA RTT is set to maximum 10 ms. | +| | | ++--------------+--------------------------------------------------------------+ +|applicability | This test case can be configured with different: | +| | | +| | * packet sizes; | +| | * burst sizes; | +| | * ping intervals; | +| | * test durations; | +| | * test iterations. | +| | | +| | Default values exist. | +| | | +| | SLA is optional. The SLA in this test case serves as an | +| | example. Considerably lower RTT is expected, and also normal | +| | to achieve in balanced L2 environments. However, to cover | +| | most configurations, both bare metal and fully virtualized | +| | ones, this value should be possible to achieve and | +| | acceptable for black box testing. Many real time | +| | applications start to suffer badly if the RTT time is higher | +| | than this. Some may suffer bad also close to this RTT, while | +| | others may not suffer at all. It is a compromise that may | +| | have to be tuned for different configuration purposes. | +| | | ++--------------+--------------------------------------------------------------+ +|usability | This test case should be run in Kunernetes environment. | +| | | ++--------------+--------------------------------------------------------------+ +|references | Ping_ | +| | | +| | ETSI-NFV-TST001 | +| | | ++--------------+--------------------------------------------------------------+ +|pre-test | The test case Docker image (openretriever/yardstick) needs | +|conditions | to be pulled into Kubernetes environment. | +| | The VM image (cirros-image) needs to be installed into | +| | Glance with ping included in it. | +| | | +| | No further requirements have been identified. | +| | | ++--------------+--------------------------------------------------------------+ +|test sequence | description and expected result | +| | | ++--------------+--------------------------------------------------------------+ +|step 1 | A containers is booted, as server and a VM is booted as | +| | client. | +| | | ++--------------+--------------------------------------------------------------+ +|step 2 | Yardstick is connected with the server container by using | +| | ssh. 'ping_benchmark' bash script is copied from Jump Host | +| | to the server container via the ssh tunnel. | +| | | ++--------------+--------------------------------------------------------------+ +|step 3 | Ping is invoked. Ping packets are sent from server container | +| | to client VM. RTT results are calculated and checked against | +| | the SLA. Logs are produced and stored. | +| | | +| | Result: Logs are stored. | +| | | ++--------------+--------------------------------------------------------------+ +|step 4 | The container and VM are deleted. | +| | | ++--------------+--------------------------------------------------------------+ +|test verdict | Test should not PASS if any RTT is above the optional SLA | +| | value, or if there is a test case execution problem. | +| | | ++--------------+--------------------------------------------------------------+ diff --git a/docs/testing/user/userguide/opnfv_yardstick_tc083.rst b/docs/testing/user/userguide/opnfv_yardstick_tc083.rst index dc00ac67a..7f80e2d98 100644 --- a/docs/testing/user/userguide/opnfv_yardstick_tc083.rst +++ b/docs/testing/user/userguide/opnfv_yardstick_tc083.rst @@ -10,11 +10,11 @@ Yardstick Test Case Description TC083 .. _netperf: http://www.netperf.org/netperf/training/Netperf.html +-----------------------------------------------------------------------------+ -|Throughput per VM test | +|Throughput per VM test | | | +--------------+--------------------------------------------------------------+ |test case id | OPNFV_YARDSTICK_TC083_Network latency and throughput between | -| | VMs | +| | VMs | | | | +--------------+--------------------------------------------------------------+ |metric | Network latency and throughput | |