summaryrefslogtreecommitdiffstats
path: root/tools/report/report.jinja
blob: 8354835c3d8c78938e8647659174848d5e090ce1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
# CHARACTERIZE VSWITCH PERFORMANCE FOR TELCO NFV USE CASES LEVEL TEST REPORT

## Table of Contents

- [1. Introduction](#Introduction)
  - [1.1. Document identifier](#DocId)
  - [1.2. Scope](#Scope)
  - [1.3. References](#References)
- [2. Details of the Level Test Report](#DetailsoftheLevelTestReport)
  - [2.1. Overview of test results](#OverviewOfTestResults)
  - [2.2. Detailed test results](#DetailedTestResults)
  - [2.3. Rationale for decisions](#RationaleForDecisions)
  - [2.4. Conclusions and recommendations](#ConclusionsandRecommendations)
- [3. General](#General)
  - [3.1. Glossary](#Glossary)
  - [3.2. Document change procedures and history](#DocChangeProceduresandHistory)

---

<a name="Introduction"></a>
## 1. Introduction

The objective of the OPNFV project titled **"Characterise vSwitch Performance
for Telco NFV Use Cases"**, is to evaluate a virtual switch to identify its
suitability for a Telco Network Function Virtualization (NFV) environment. As
well as this, the project aims to identify any gaps or bottlenecks in order to
drive architectural changes to improve virtual switch performance and
determinism. The purpose of this document is to summarize the results of the
tests carried out on the virtual switch in the Network Function Virtualization
Infrastructure (NFVI) and, from these results, provide evaluations and
recommendations for the virtual switch. Test results will be outlined in
[Details of the Level Test Report](#DetailsoftheLevelTestReport), preceded by
the [Document Identifier](#DocId), [Scope](#Scope) and
[References](#References).

This document is currently in draft form.

<a name="DocId"></a>
### 1.1. Document identifier

The document id will be used to uniquely identify versions of the LTR. The
format for the document id will be:
`OPNFV_vswitchperf_LTR_ver_NUM_MONTH_YEAR_AUTHOR_STATUS`, where by the AUTHOR
field should be replaced with the initials of the author and the status is one
of: DRAFT, REVIEWED, CORRECTED or FINAL. The document id for this version of
the LTR is: `OPNFV_vswitchperf_LTR_ver_1.1_Jan_15_CN_DRAFT`.

<a name="Scope"></a>
### 1.2. Scope

The scope of this report is to detail the results of the tests that have been
performed on the virtual switch. This report will also evaluate the results of
these tests and, based on these evaluations, provide recommendations on the
suitability of the virtual switch for use in a Telco NFV environment.

<a name="References"></a>
### 1.3. References

- `OPNFV_vswitchperf_LTD_ver_1.6_Jan_15_DRAFT`

---

<a name="DetailsoftheLevelTestReport"></a>
## 2. Details of the Level Test Report

This section provides an overview of the test results ([Section
2.1.](#OveriewOfTestResults)) as well as detailed test results for each test
([Section 2.2.](#DetailedTestResults)). Also included are the rationale used to
evaluate each test ([Section 2.3.](#RationaleForDecisions)) and the conclusions
and recommendations for each test ([Section
2.4.](#ConclusionsandRecommendations)).

<a name="OverviewOfTestResults"></a>
### 2.1. Overview of test results

##### Test Environment

Below is the environment that the test was performed in:

- OS: {{tests[0].env.os}}
- Kernel Version: {{tests[0].env.kernel}}
- NIC(s):{% for nic in tests[0].env.nics %}
    - {{nic}}{% endfor %}
- Board: {{tests[0].env.platform}}
- CPU: {{tests[0].env.cpu}}
- CPU cores: {{tests[0].env.cpu_cores}}
- Memory: {{tests[0].env.memory}}
- Virtual Switch Set-up: {{tests[0].deployment}}
- vswitchperf: GIT tag: {{tests[0].env.vsperf['git_tag']}}
- Traffic Generator: {{tests[0].env.traffic_gen['name']}}, Version: {{tests[0].env.traffic_gen['version']}}, GIT tag: {{tests[0].env.traffic_gen['git_tag']}}
- vSwitch: {{tests[0].env.vswitch['name']}}, Version: {{tests[0].env.vswitch['version']}}, GIT tag: {{tests[0].env.vswitch['git_tag']}}
{%- if 'dpdk' in tests[0].env %}
- DPDK Version: {{tests[0].env.dpdk['version']}}, GIT tag: {{tests[0].env.dpdk['git_tag']}}
{%- endif %}
{%- if 'vnf' in tests[0].env %}
- VNF: {{tests[0].env.vnf['name']}}, Version: {{tests[0].env.vnf['version']}}, GIT tag: {{tests[0].env.vnf['git_tag']}}
- VM images:{% for guest_image in tests[0].env.guest_image %}
    - {{guest_image}}{% endfor %}
- VM loopback apps:{% for loopback_app in tests[0].env.loopback_app %}
    - {{loopback_app['name']}}, Version: {{loopback_app['version']}}, GIT tag: {{loopback_app['git_tag']}}{% endfor %}
{%- endif %}

For each test, a summary of the key test results is provided.
{% for test in tests %}
#### Test ID: {{ test.ID }}

Below are test details:

- Test ID: {{ "%s"|format(test.id) }}
- Description: {{ "%s"|format(test.conf['Description']) }}
- Deployment: {{ "%s"|format(test.deployment) }}
- Traffic type: {{ "%s"|format(test.result['type']) }}
- Packet size: {{ "%s"|format(test.result['packet_size']) }}
- Bidirectional : {{ "%s"|format(test.conf['biDirectional']) }}
{%- if test.result['tunnel_type'] %}
- Tunnel type: {{ "%s"|format(test.result['tunnel_type']) }}
{%- endif %}
{% endfor %}

<a name="DetailedTestResults"></a>
### 2.2. Detailed test results

A detailed summary of the main results for each test is outlined below.
{% for test in tests %}
#### Test ID: {{ test.ID }}

##### Results/Metrics Collected

The following are the metrics obtained during this test:

|             Metric             |             Result             |
| ------------------------------ | ------------------------------ |
{%- for item, value in test.result.items() %}
| {{ "%-30s | %30s |"|format(item,value)}}
{%- endfor %}

##### Statistics collected

The following system statistics were collected during testcase execution:
{% for process in test.stats %}
| --------------------------------------------------------------- |
| Process: {{ "%-54s |"|format('_'.join(process.split('_')[:-1])) }}
| ------------------------------ | ------------------------------ |
|           Statistic            |             Value              |
| ------------------------------ | ------------------------------ |
{%- for item, value in test.stats[process].items() %}
| {{ "%-30s | %30s |"|format(item,value)}}
{%- endfor %}

{% endfor %}

##### Anomalies

No anomalies were detected during the course of this test.

##### Testing Activities/Events

There were no significant testing activities for this test.
{% endfor %}
<a name="RationaleForDecisions"></a>
### 2.3. Rationale for decisions

The tests conducted do not have pass/fail/conditional-pass criteria. The test
is simply conducted and the results are reported.


<a name="ConclusionsandRecommendations"></a>
### 2.4. Conclusions and recommendations

The test results are stable. The vsperf CI jobs that were used to obtain the
results can be found at https://wiki.opnfv.org/wiki/vsperf_results.

-----

<a name="General"></a>
## 3. General

<a name="Glossary"></a>
### 3.1. Glossary

- NFV - Network Function Virtualization
- Mbps - 1,000,000bps

<a name="DocChangeProceduresandHistory"></a>
### 3.2. Document change procedures and history

| Document ID | Author | Date Modified |
| ----------- |------- | ------------- |
| `OPNFV_vswitchperf_LTR_ver_1.0_Jan_15_CN_DRAFT` | Christopher Nolan | 23/01/2015
| `OPNFV_vswitchperf_LTR_ver_1.1_Jan_15_CN_DRAFT` | Christopher Nolan | 28/01/2015
sage: functest testcase [OPTIONS] COMMAND [ARGS]... Options: -h, --help Show this message and exit. Commands: list Lists the available testcases. run Executes a test case. show Shows information about a test case. More details on the existing Tiers and Test Cases can be seen with the 'list' command:: root@22e436918db0:~/repos/functest/ci# functest tier list - 0. healthcheck: ['healthcheck', 'connection_check', 'api_check',] - 1. smoke: ['vping_ssh', 'vping_userdata', 'tempest_smoke_serial', 'rally_sanity', 'snaps_smoke', 'odl'] - 2. features: ['doctor', 'security_scan'] - 3. components: ['tempest_full_parallel', 'rally_full'] - 4. vnf: ['cloudify_ims'] and root@22e436918db0:~/repos/functest/ci# functest testcase list healthcheck api_check connection_check vping_ssh vping_userdata snaps_smoke tempest_smoke_serial rally_sanity odl doctor security_scan tempest_full_parallel rally_full cloudify_ims More specific details on specific Tiers or Test Cases can be seen wih the 'show' command:: root@22e436918db0:~/repos/functest/ci# functest tier show smoke +======================================================================+ | Tier: smoke | +======================================================================+ | Order: 1 | | CI Loop: (daily)|(weekly) | | Description: | | Set of basic Functional tests to validate the OpenStack | | deployment. | | Test cases: | | - vping_ssh | | - vping_userdata | | - tempest_smoke_serial | | - rally_sanity | | | +----------------------------------------------------------------------+ and root@22e436918db0:~/repos/functest/ci# functest testcase show tempest_smoke_serial +======================================================================+ | Testcase: tempest_smoke_serial | +======================================================================+ | Description: | | This test case runs the smoke subset of the OpenStack Tempest | | suite. The list of test cases is generated by Tempest | | automatically and depends on the parameters of the OpenStack | | deplopyment. | | Dependencies: | | - Installer: | | - Scenario : | | | +----------------------------------------------------------------------+ To execute a Test Tier or Test Case, the 'run' command is used:: root@22e436918db0:~/repos/functest/ci# functest tier run healthcheck Executing command: 'python /home/opnfv/repos/functest/ci/run_tests.py -t healthcheck' 2016-06-30 11:44:56,933 - run_tests - INFO - Sourcing the OpenStack RC file... 2016-06-30 11:44:56,937 - run_tests - INFO - ############################################ 2016-06-30 11:44:56,938 - run_tests - INFO - Running tier 'healthcheck' 2016-06-30 11:44:56,938 - run_tests - INFO - ############################################ 2016-06-30 11:44:56,938 - run_tests - INFO - ============================================ 2016-06-30 11:44:56,938 - run_tests - INFO - Running test case 'healthcheck'... 2016-06-30 11:44:56,938 - run_tests - INFO - ============================================ 2016-06-30 11:44:56,953 - healtcheck - INFO - Testing Keystone API... 2016-06-30 11:45:05,351 - healtcheck - INFO - ...Keystone OK! 2016-06-30 11:45:05,354 - healtcheck - INFO - Testing Glance API... 2016-06-30 11:45:29,746 - healtcheck - INFO - ... Glance OK! 2016-06-30 11:45:29,749 - healtcheck - INFO - Testing Cinder API... 2016-06-30 11:45:37,502 - healtcheck - INFO - ...Cinder OK! 2016-06-30 11:45:37,505 - healtcheck - INFO - Testing Neutron API... 2016-06-30 11:45:39,664 - healtcheck - INFO - External network found. ccd98ad6-d34a-4768-b03c-e28ecfcd51ca 2016-06-30 11:45:39,667 - healtcheck - INFO - 1. Create Networks... 2016-06-30 11:45:44,227 - healtcheck - INFO - 2. Create subnets... 2016-06-30 11:45:46,805 - healtcheck - INFO - 4. Create Routers... 2016-06-30 11:45:54,261 - healtcheck - INFO - ...Neutron OK! 2016-06-30 11:45:54,264 - healtcheck - INFO - Testing Nova API... 2016-06-30 11:47:12,272 - healtcheck - INFO - ...Nova OK! 2016-06-30 11:47:12,274 - healtcheck - INFO - Checking if instances get an IP from DHCP... : : 2016-06-30 11:48:17,832 - healtcheck - INFO - ...DHCP OK! 2016-06-30 11:48:17,835 - healtcheck - INFO - Health check passed! 2016-06-30 11:48:17,837 - clean_openstack - INFO - +++++++++++++++++++++++++++++++ 2016-06-30 11:48:17,837 - clean_openstack - INFO - Cleaning OpenStack resources... 2016-06-30 11:48:17,837 - clean_openstack - INFO - +++++++++++++++++++++++++++++++ Version 1 is deprecated, use alternative version 2 instead. WARNING:cinderclient.api_versions:Version 1 is deprecated, use alternative version 2 instead. 2016-06-30 11:48:18,272 - clean_openstack - INFO - Removing Nova instances... 2016-06-30 11:48:24,439 - clean_openstack - INFO - ------------------------------------------- 2016-06-30 11:48:24,440 - clean_openstack - INFO - Removing Glance images... 2016-06-30 11:48:35,853 - clean_openstack - INFO - ------------------------------------------- 2016-06-30 11:48:35,854 - clean_openstack - INFO - Removing Cinder volumes... 2016-06-30 11:48:37,344 - clean_openstack - INFO - ------------------------------------------- 2016-06-30 11:48:37,344 - clean_openstack - INFO - Removing floating IPs... 2016-06-30 11:48:37,467 - clean_openstack - INFO - ------------------------------------------- 2016-06-30 11:48:37,467 - clean_openstack - INFO - Removing Neutron objects 2016-06-30 11:48:53,633 - clean_openstack - INFO - ------------------------------------------- 2016-06-30 11:48:53,633 - clean_openstack - INFO - Removing Security groups... 2016-06-30 11:48:53,689 - clean_openstack - INFO - ------------------------------------------- 2016-06-30 11:48:53,689 - clean_openstack - INFO - Removing Users... 2016-06-30 11:48:54,444 - clean_openstack - INFO - ------------------------------------------- 2016-06-30 11:48:54,444 - clean_openstack - INFO - Removing Tenants... 2016-06-30 11:48:54,711 - clean_openstack - INFO - ------------------------------------------- and root@22e436918db0:~/repos/functest/ci# functest testcase run vping_ssh Executing command: 'python /home/opnfv/repos/functest/ci/run_tests.py -t vping_ssh' 2016-06-30 11:50:31,861 - run_tests - INFO - Sourcing the OpenStack RC file... 2016-06-30 11:50:31,865 - run_tests - INFO - ============================================ 2016-06-30 11:50:31,865 - run_tests - INFO - Running test case 'vping_ssh'... 2016-06-30 11:50:31,865 - run_tests - INFO - ============================================ 2016-06-30 11:50:32,977 - vping_ssh - INFO - Creating image 'functest-vping' from '/home/opnfv/functest/data/cirros-0.3.5-x86_64-disk.img'... 2016-06-30 11:50:45,470 - vping_ssh - INFO - Creating neutron network vping-net... 2016-06-30 11:50:47,645 - vping_ssh - INFO - Creating security group 'vPing-sg'... 2016-06-30 11:50:48,843 - vping_ssh - INFO - Using existing Flavor 'm1.small'... 2016-06-30 11:50:48,927 - vping_ssh - INFO - vPing Start Time:'2016-06-30 11:50:48' 2016-06-30 11:50:48,927 - vping_ssh - INFO - Creating instance 'opnfv-vping-1'... 2016-06-30 11:51:34,664 - vping_ssh - INFO - Instance 'opnfv-vping-1' is ACTIVE. 2016-06-30 11:51:34,818 - vping_ssh - INFO - Adding 'opnfv-vping-1' to security group 'vPing-sg'... 2016-06-30 11:51:35,209 - vping_ssh - INFO - Creating instance 'opnfv-vping-2'... 2016-06-30 11:52:01,439 - vping_ssh - INFO - Instance 'opnfv-vping-2' is ACTIVE. 2016-06-30 11:52:01,439 - vping_ssh - INFO - Adding 'opnfv-vping-2' to security group 'vPing-sg'... 2016-06-30 11:52:01,754 - vping_ssh - INFO - Creating floating IP for VM 'opnfv-vping-2'... 2016-06-30 11:52:01,969 - vping_ssh - INFO - Floating IP created: '10.17.94.140' 2016-06-30 11:52:01,969 - vping_ssh - INFO - Associating floating ip: '10.17.94.140' to VM 'opnfv-vping-2' 2016-06-30 11:52:02,792 - vping_ssh - INFO - Trying to establish SSH connection to 10.17.94.140... 2016-06-30 11:52:19,915 - vping_ssh - INFO - Waiting for ping... 2016-06-30 11:52:21,108 - vping_ssh - INFO - vPing detected! 2016-06-30 11:52:21,108 - vping_ssh - INFO - vPing duration:'92.2' s. 2016-06-30 11:52:21,109 - vping_ssh - INFO - vPing OK 2016-06-30 11:52:21,153 - clean_openstack - INFO - +++++++++++++++++++++++++++++++ 2016-06-30 11:52:21,153 - clean_openstack - INFO - Cleaning OpenStack resources... 2016-06-30 11:52:21,153 - clean_openstack - INFO - +++++++++++++++++++++++++++++++ Version 1 is deprecated, use alternative version 2 instead. : : etc. To list the test cases which are part of a specific Test Tier, the 'get-tests' command is used with 'functest tier':: root@22e436918db0:~/repos/functest/ci# functest tier get-tests healthcheck Test cases in tier 'healthcheck': ['healthcheck'] Please note that for some scenarios some test cases might not be launched. For example, the last example displayed only the 'odl' testcase for the given environment. In this particular system the deployment does not support the 'onos' SDN Controller Test Case; for example. **Important** If you use the command 'functest tier run <tier_name>', then the Functest CLI utility will call **all valid Test Cases**, which belong to the specified Test Tier, as relevant to scenarios deployed to the SUT environment. Thus, the Functest CLI utility calculates automatically which tests can be executed and which cannot, given the environment variable **DEPLOY_SCENARIO**, which is passed in to the Functest docker container. Currently, the Functest CLI command 'functest testcase run <testcase_name>', supports two possibilities:: * Run a single Test Case, specified by a valid choice of <testcase_name> * Run ALL test Test Cases (for all Tiers) by specifying <testcase_name> = 'all' Functest includes a cleaning mechanism in order to remove all the OpenStack resources except those present before running any test. The script *$REPOS_DIR/functest/functest/utils/generate_defaults.py* is called once when setting up the Functest environment (i.e. CLI command 'functest env prepare') to snapshot all the OpenStack resources (images, networks, volumes, security groups, tenants, users) so that an eventual cleanup does not remove any of these defaults. The script **clean_openstack.py** which is located in *$REPOS_DIR/functest/functest/utils/* is normally called after a test execution. It is in charge of cleaning the OpenStack resources that are not specified in the defaults file generated previously which is stored in */home/opnfv/functest/conf/os_defaults.yaml* in the Functest docker container. It is important to mention that if there are new OpenStack resources created manually after preparing the Functest environment, they will be removed, unless you use the special method of invoking the test case with specific suppression of clean up. (See the `Troubleshooting`_ section). The reason to include this cleanup meachanism in Functest is because some test suites such as Tempest or Rally create a lot of resources (users, tenants, networks, volumes etc.) that are not always properly cleaned, so this function has been set to keep the system as clean as it was before a full Functest execution. Although the Functest CLI provides an easy way to run any test, it is possible to do a direct call to the desired test script. For example: python $REPOS_DIR/functest/functest/opnfv_tests/OpenStack/vPing/vPing_ssh.py -d Automated testing ----------------- As mentioned previously, the Functest Docker container preparation as well as invocation of Test Cases can be called within the container from the Jenkins CI system. There are 3 jobs that automate the whole process. The first job runs all the tests referenced in the daily loop (i.e. that must been run daily), the second job runs the tests referenced in the weekly loop (usually long duration tests run once a week maximum) and the third job allows testing test suite by test suite specifying the test suite name. The user may also use either of these Jenkins jobs to execute the desired test suites. One of the most challenging task in the Danube release consists in dealing with lots of scenarios and installers. Thus, when the tests are automatically started from CI, a basic algorithm has been created in order to detect whether a given test is runnable or not on the given scenario. Some Functest test suites cannot be systematically run (e.g. ODL suite can not be run on an ONOS scenario). The daily/weekly notion has been introduces in Colorado in order to save CI time and avoid running systematically long duration tests. It was not used in Colorado due to CI resource shortage. The mechanism remains however as part of the CI evolution. CI provides some useful information passed to the container as environment variables: * Installer (apex|compass|daisy|fuel|joid), stored in INSTALLER_TYPE * Installer IP of the engine or VM running the actual deployment, stored in INSTALLER_IP * The scenario [controller]-[feature]-[mode], stored in DEPLOY_SCENARIO with * controller = (odl|onos|ocl|nosdn) * feature = (ovs(dpdk)|kvm|sfc|bgpvpn|multisites) * mode = (ha|noha) The constraints per test case are defined in the Functest configuration file */home/opnfv/repos/functest/functest/ci/testcases.yaml*:: tiers: - name: healthcheck order: 0 ci_loop: '(daily)|(weekly)' description : >- First tier to be executed to verify the basic operations in the VIM. testcases: - name: healthcheck criteria: 'status == "PASS"' blocking: true description: >- This test case verifies the basic OpenStack services like Keystone, Glance, Cinder, Neutron and Nova. dependencies: installer: '' scenario: '' - name: smoke order: 1 ci_loop: '(daily)|(weekly)' description : >- Set of basic Functional tests to validate the OpenStack deployment. testcases: - name: vping_ssh criteria: 'status == "PASS"' blocking: true description: >- This test case verifies: 1) SSH to an instance using floating IPs over the public network. 2) Connectivity between 2 instances over a private network. dependencies: installer: '' scenario: '^((?!bgpvpn|odl_l3).)*$' run: module: 'functest.opnfv_tests.openstack.vping.vping_ssh' class: 'VPingSSH' .... We may distinguish 2 levels in the test case description: * Tier level * Test case level At the tier level, we define the following parameters: * ci_loop: indicate if in automated mode, the test case must be run in daily and/or weekly jobs * description: a high level view of the test case For a given test case we defined: * the name of the test case * the criteria (experimental): a criteria used to declare the test case as PASS or FAIL * blocking: if set to true, if the test is failed, the execution of the following tests is canceled * the description of the test case * the dependencies: a combination of 2 regex on the scenario and the installer name * run: In Danube we introduced the notion of abstract class in order to harmonize the way to run internal, feature or vnf tests For further details on abstraction classes, see developper guide. Additional parameters have been added in the desription in the Database. The target is to use the configuration stored in the Database and consider the local file as backup if the Database is not reachable. The additional fields related to a test case are: * trust: we introduced this notion to put in place a mechanism of scenario promotion. * Version: it indicates since which version you can run this test * domains: the main domain covered by the test suite * tags: a list of tags related to the test suite The order of execution is the one defined in the file if all test cases are selected. In CI daily job the tests are executed in the following order: 1) healthcheck (blocking) 2) smoke: both vPings are blocking 3) Feature project tests cases In CI weekly job we add 2 tiers: 4) VNFs (vIMS) 5) Components (Rally and Tempest long duration suites) As explained before, at the end of an automated execution, the OpenStack resources might be eventually removed. Please note that a system snapshot is taken before any test case execution. This testcase.yaml file is used for CI, for the CLI and for the automatic reporting.