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
|
.. This work is licensed under a Creative Commons Attribution 4.0 International
.. License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) 2016 Huawei Technologies Co.,Ltd and others
============
Architecture
============
Abstract
========
This chapter describes the yardstick framework software architecture. we will introduce it from Use-Case View,
Logical View, Process View and Deployment View. More technical details will be introduced in this chapter.
Overview
========
Architecture overview
---------------------
Yardstick is mainly written in Python, and test configurations are made
in YAML. Documentation is written in reStructuredText format, i.e. .rst
files. Yardstick is inspired by Rally. Yardstick is intended to run on a
computer with access and credentials to a cloud. The test case is described
in a configuration file given as an argument.
How it works: the benchmark task configuration file is parsed and converted into
an internal model. The context part of the model is converted into a Heat
template and deployed into a stack. Each scenario is run using a runner, either
serially or in parallel. Each runner runs in its own subprocess executing
commands in a VM using SSH. The output of each scenario is written as json
records to a file or influxdb or http server, we use influxdb as the backend,
the test result will be shown with grafana.
Concept
-------
**Benchmark** - assess the relative performance of something
**Benchmark** configuration file - describes a single test case in yaml format
**Context** - The set of Cloud resources used by a scenario, such as user
names, image names, affinity rules and network configurations. A context is
converted into a simplified Heat template, which is used to deploy onto the
Openstack environment.
**Data** - Output produced by running a benchmark, written to a file in json format
**Runner** - Logic that determines how a test scenario is run and reported, for
example the number of test iterations, input value stepping and test duration.
Predefined runner types exist for re-usage, see `Runner types`_.
**Scenario** - Type/class of measurement for example Ping, Pktgen, (Iperf, LmBench, ...)
**SLA** - Relates to what result boundary a test case must meet to pass. For
example a latency limit, amount or ratio of lost packets and so on. Action
based on :term:`SLA` can be configured, either just to log (monitor) or to stop
further testing (assert). The :term:`SLA` criteria is set in the benchmark
configuration file and evaluated by the runner.
Runner types
------------
There exists several predefined runner types to choose between when designing
a test scenario:
**Arithmetic:**
Every test run arithmetically steps the specified input value(s) in the
test scenario, adding a value to the previous input value. It is also possible
to combine several input values for the same test case in different
combinations.
Snippet of an Arithmetic runner configuration:
::
runner:
type: Arithmetic
iterators:
-
name: stride
start: 64
stop: 128
step: 64
**Duration:**
The test runs for a specific period of time before completed.
Snippet of a Duration runner configuration:
::
runner:
type: Duration
duration: 30
**Sequence:**
The test changes a specified input value to the scenario. The input values
to the sequence are specified in a list in the benchmark configuration file.
Snippet of a Sequence runner configuration:
::
runner:
type: Sequence
scenario_option_name: packetsize
sequence:
- 100
- 200
- 250
**Iteration:**
Tests are run a specified number of times before completed.
Snippet of an Iteration runner configuration:
::
runner:
type: Iteration
iterations: 2
Use-Case View
=============
TBD(kubi)
Logical View
============
TBD(Qiliang)
Process View (Test execution flow)
==================================
TBD(Limingjiang)
Deployment View
===============
TBD(Patrick)
Yardstick Directory structure
=============================
**yardstick/** - Yardstick main directory.
*ci/* - Used for continuous integration of Yardstick at different PODs and
with support for different installers.
*docs/* - All documentation is stored here, such as configuration guides,
user guides and Yardstick descriptions.
*etc/* - Used for test cases requiring specific POD configurations.
*samples/* - test case samples are stored here, most of all scenario and
feature's samples are shown in this directory.
*tests/* - Here both Yardstick internal tests (*functional/* and *unit/*) as
well as the test cases run to verify the NFVI (*opnfv/*) are stored.
Also configurations of what to run daily and weekly at the different
PODs is located here.
*tools/* - Currently contains tools to build image for VMs which are deployed
by Heat. Currently contains how to build the yardstick-trusty-server
image with the different tools that are needed from within the image.
*vTC/* - Contains the files for running the virtual Traffic Classifier tests.
*yardstick/* - Contains the internals of Yardstick: Runners, Scenario, Contexts,
CLI parsing, keys, plotting tools, dispatcher and so on.
|
