summaryrefslogtreecommitdiffstats
path: root/docs/release/results/results.rst
blob: c75f5ae940ce329445848781b7d40dd04371a3f6 (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
.. This work is licensed under a Creative Commons Attribution 4.0 International
.. License.
.. http://creativecommons.org/licenses/by/4.0

Results listed by test cases
==========================

.. _TOM: https://wiki.opnfv.org/display/testing/R+post-processing+of+the+Yardstick+results


The following sections describe the yardstick test case results as evaluated
for the OPNFV Fraser release scenario validation runs. Each section describes
the determined state of the specific test case as executed in the Fraser release
process. All test date are analyzed using TOM_ tool.

Scenario Results
================

.. _Dashboard: http://testresults.opnfv.org/grafana/dashboard/db/yardstick-main
.. _Jenkins: https://build.opnfv.org/ci/view/yardstick/


The following documents contain results of Yardstick test cases executed on
OPNFV labs, triggered by OPNFV CI pipeline, documented per test case.


.. toctree::
   :maxdepth: 1

   tc002-network-latency.rst
   tc010-memory-read-latency.rst
   tc011-packet-delay-variation.rst
   tc012-memory-read-write-bandwidth.rst
   tc014-cpu-processing-speed.rst
   tc069-memory-write-bandwidth.rst
   tc082-context-switches-under-load.rst
   tc083-network-throughput-between-vm.rst

Test results of executed tests are avilable in Dashboard_ and logs in Jenkins_.


Feature Test Results
====================

The following features were verified by Yardstick test cases:

   * IPv6

   * HA (see :doc:`yardstick-opnfv-ha`)

   * KVM

   * Parser

   * Virtual Traffic Classifier (see :doc:`yardstick-opnfv-vtc`)

   * StorPerf

.. note:: The test cases for IPv6 and Parser Projects are included in the
  compass scenario.
pan class="o">= {}, $purge_firewall_rules = false, $firewall_pre_extras = {}, $firewall_post_extras = {}, ) { if $manage_firewall { # Only purges IPv4 rules if $purge_firewall_rules { resources { 'firewall': purge => true } } # anyone can add your own rules # example with Hiera: # # tripleo::firewall::firewall_rules: # '300 allow custom application 1': # port: 999 # proto: udp # action: accept # '301 allow custom application 2': # port: 8081 # proto: tcp # action: accept # create_resources('tripleo::firewall::rule', $firewall_rules) ensure_resource('class', 'tripleo::firewall::pre', { 'firewall_settings' => $firewall_pre_extras, }) ensure_resource('class', 'tripleo::firewall::post', { 'firewall_settings' => $firewall_post_extras, }) Class['tripleo::firewall::pre'] -> Class['tripleo::firewall::post'] Service<||> -> Class['tripleo::firewall::post'] # Allow composable services to load their own custom # example with Hiera. # NOTE(dprince): In the future when we have a better hiera # heat hook we might refactor this to use hiera's merging # capabilities instead. Until then rolling up the flat service # keys and dynamically creating firewall rules for each service # will allow us to compose and should work fine. # # Each service can load its rules by using this form: # # tripleo.<service name with underscores>.firewall_rules: # '300 allow custom application 1': # dport: 999 # proto: udp # action: accept $service_names = hiera('service_names', []) tripleo::firewall::service_rules { $service_names: } } }