Age | Commit message (Collapse) | Author | Files | Lines |
|
List of changes:
- Added new scenario NSPerf-RFC2544 that runs complete test per
runner's iteration
- NSPerf is still present for backward compatibility
- Added ScenarioOutput class which allows scenario to report
data (kpi,...) at any moment of time (not only once per run)
- New output mechanism is used only by new NSPerf-RFC2544 scenario
JIRA: YARDSTICK-1592
Change-Id: Ica8078f61d895f74df90e8eaad7a675b28bd19c6
Signed-off-by: Serhiy Pshyk <serhiyx.pshyk@intel.com>
|
|
The existing implementation of IPC is not finished and isn't used
by any of the VNFs/TG implementation. It is used in the code but does
nothing from functionality perspective.
New syncronization mechanism is going to be implemented by using
different approach than it was designed before. Thus, the current
IPC mechanism is not going to be re-used. So, removing it.
The IPC consumer/producer implementation is left as it may be
required for other purposes.
- Remove SampleVNF MQ consumer class
- Remove IterationIPC MQ producer for VNF control messages
- Remove MQ producer from SampleVNFTrafficGen class
- Remove TrafficGeneratorProducer class
- Remove IterationIPC runner
- Remove unused task_id form VNF Generic initialization as it is not
required for synchronization of VNFs/TGs anymore.
- Fix UT
JIRA: YARDSTICK-1592
Change-Id: I65fe51bcbd1bfeea0c43eb79ca6fb2aab5b65ae7
Signed-off-by: Mytnyk, Volodymyr <volodymyrx.mytnyk@intel.com>
|
|
"IterationIPC" runner class is a consumer for MQ aware VNFs. A MQ aware
traffic generator can send "started", "finished" and "iteration"
messages.
This feature implements a MQ producer in the runner in order to send
messages to the VNFs. The messages implemented are:
- "start_iteration"
- "stop_iteration"
JIRA: YARDSTICK-1286
Change-Id: I706f9a9dda5e5beed52231be7d71452945a7dbed
Signed-off-by: Rodolfo Alonso Hernandez <rodolfo.alonso.hernandez@intel.com>
|
|
atexit handler calls terminate_all after the regular python execution
path, and it looks like the traceback stack is None somehow.
In this context log.debug("", exc_info=True) doesn't work
it prints out NoneType on Python3 and
causes other problems on Python2.7
remove the exc_info=True from the logging call
JIRA: YARDSTICK-1107
Change-Id: Ida0a0ced7ff5e017e2f8608880e3bb531724af95
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
JIRA: YARDSTICK-989
We used to have real-time influxdb reporting of test KPIs. The user
could monitor using grafana and see the real-time output.
The record format was changed to now only report KPIs at the end of the
test.
This is a problem for test cases which run for a long duration, we need
to wait until the end of the test execution to get any results from
influxdb. If the test fails in between or doesn't exit cleanly for some
reason, we are left with no results stored in influxdb which gives the
user no information.
This is also a regression from the previous behaviour.
Change-Id: I0f476dff9162a359f0286fb421f2e9c4befaa5cc
Signed-off-by: chenjiankun <chenjiankun1@huawei.com>
|
|
We were not draining the queues in the background
runners.
Modify the main runner_join loop to loop over
all the runners and drain them.
The runner join method does extra work for periodic actions
so we can't change its behavior.
Instead create a new poll() method and use that
to check runner status
Change-Id: I9466ba40a6a4c45c82cedff279cbb4817c6b66ad
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
The PROX tests were hanging in the duration
runner.
These are fixes for various errors:
raise error in collect_kpi if VNF is down
move prox dpdk_rebind after collectd stop
fix dpdk nicbind rebind to group by drivers
prox: raise error in collect_kpi if the VNF is down
prox: add VNF_TYPE for consistency
sample_vnf: debug and fix kill_vnf
pkill is not matching some executable names,
add some debug process dumps and try switching
back to killall until we can find the issue
sample_vnf: add default timeout, so we can override
default 3600 SSH timeout
collect_kpi is the point at which we check
the VNFs and TGs for failures or exits
queues are the problem make sure we aren't silently blocking on
non-empty queues by canceling join thread in subprocess
fixup duration runner to close queues
and other attempt to stop duration runner
from hanging
VnfdHelper: memoize port_num
resource: fail if ssh can't connect
at the end of 3600 second test our ssh connection
is dead, so we can't actually stop collectd
unless we reconnect
fix stop() logic to ignore ssh errors
Change-Id: I6c8e682a80cb9d00362e2fef4a46df080f304e55
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
Sometimes the runners can hang. Initially
debugging lead to the queue join thread, so I thought
we could cancel all the join threads and everything would be okay.
But it turns out canceling the queue join threads can lead
to corruption of the queues, so when we go to drain the queues
the task hangs.
But it also turns out that we were not properly draining
the queues in the task process. We were waiting for all
the runners to exit, then draining the queues.
This is bad and will cause the queues to fill up and hang
and/or drop data or corrupt the queues.
The proper fix seems to be to draining the queues in a
loop before calling join with a timeout.
Also modified the queue drain loops to no block on queue.get()
Revert "cancel all queue join threads"
This reverts commit 75c0e3a54b8f6e8fd77c7d9d95decab830159929.
Revert "duration runner: add teardown and cancel all queue join threads"
This reverts commit 7eb6abb6931b24e085b139cc3500f4497cdde57d.
Change-Id: Ic4f8e814cf23615621c1250535967716b425ac18
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
In some cases we are blocking in base.Runner join() because the
queues are not empty
call cancel_join_thread to prevent the Queue from blocking the
Process exit
https://docs.python.org/3.3/library/multiprocessing.html#all-platforms
Joining processes that use queues
Bear in mind that a process that has put items in a queue will wait
before terminating until all the buffered items are fed by the
"feeder" thread to the underlying pipe. (The child process can call
the cancel_join_thread() method of the queue to avoid this behaviour.)
This means that whenever you use a queue you need to make sure that
all items which have been put on the queue will eventually be removed
before the process is joined. Otherwise you cannot be sure that
processes which have put items on the queue will terminate. Remember
also that non-daemonic processes will be joined automatically.
Warning
As mentioned above, if a child process has put items on a queue (and
it has not used JoinableQueue.cancel_join_thread), then that process
will not terminate until all buffered items have been flushed to the
pipe.
This means that if you try joining that process you may get a deadlock
unless you are sure that all items which have been put on the queue
have been consumed. Similarly, if the child process is non-daemonic
then the parent process may hang on exit when it tries to join all its
non-daemonic children.
cancel_join_thread()
Prevent join_thread() from blocking. In particular, this prevents the
background thread from being joined automatically when the process
exits – see join_thread().
A better name for this method might be allow_exit_without_flush(). It
is likely to cause enqueued data to lost, and you almost certainly
will not need to use it. It is really only there if you need the
current process to exit immediately without waiting to flush enqueued
data to the underlying pipe, and you don’t care about lost data.
Change-Id: I345c722a752bddf9f0824a11cdf52ae9f04669af
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
PROX was added to samplevnf project
https://git.opnfv.org/samplevnf/tree/VNFs/DPPD-PROX
JIRA: YARDSTICK-638
Change-Id: If9875b1130c6bed87deb8720b0d8b28ede9289d9
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
JIRA: YARDSTICK-658
Currently the yardstick have three dispatcher: file, influxdb, mongodb.
(influxdb using API to get result and mongodb using testAPI to get result)
But their output format is different. It is hard to use.
In this patch, make all dispatchers using the same data source.
And make the output format of file and influxdb unified.
As for mongodb, since it is related to testAPI, so I make it push data
every test case.
The unified output format is:
http://paste.openstack.org/show/610125/
Change-Id: I854ac4f03e6f904469b07b0c924c7d850545ae5b
Signed-off-by: chenjiankun <chenjiankun1@huawei.com>
|
|
JIRA: YARDSTICK-641
Allowing parameters to pass between scenarios so that the one test case
can be combination of several scenarios.
Change-Id: I55a00855e77d5b719a27a069a3ea195d6bbd0ef8
Signed-off-by: chenjiankun <chenjiankun1@huawei.com>
|
|
JIRA: YARDSTICK-632
When we use http dispatcher to output yardstick result.
It can upload data, but when we query the data, it get a KeyError.
Change-Id: I5410c207c68cff2621ff8184ae17daa4c286cea5
Signed-off-by: chenjiankun <chenjiankun1@huawei.com>
|
|
in parallel
JIRA: YARDSTICK-575
Currently yardstick will create stacks with the same name when run using
API in parallel.
The reason is there is a global variable in context base and the core
will always deploy the first context in Context.list. When run in
parallel, it will run in the one process. So yardstick will deploy
stacks with the same name.
The solution is do not use Context.list in yardstick core. And using a
local variable instead.
BTW, if we use API to call yardstick core, we can not config the output
way. So I parse yardstick.conf when task start. And I think we can
include scenario_cfg, context_cfg, yardstick_cfg in one config object
later so that we can get all config in one object.
Change-Id: I1ada4ef486bd252e78c3a2e49c6a39b3f8f16a7c
Signed-off-by: chenjiankun <chenjiankun1@huawei.com>
|
|
Change-Id: I2fad46b07b252f898acfe116dd6542946b8a26a8
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
|
|
JIRA: YARDSTICK-525
For consistency, we always use """triple double quotes""" around
docstrings.
Change-Id: I47a20bbd8b55bc544b4841ea4006929af0a044ac
Signed-off-by: chenjiankun <chenjiankun1@huawei.com>
|
|
Porting to Python3 using Openstack guidelines:
https://wiki.openstack.org/wiki/Python3
This passes unittests on Python 3.5 and passes opnfv_smoke suite
Updates:
use six for urlparse and urlopen
fix exception.message attribute removal
run unittests on python3
use unitest.mock on python 3
fix open mock for vsperf
fix float division by using delta/eplison comparison
use unicode in StringIO
use plugin/sample_config.yaml relative path from test case
fixed apexlake unittests
upgraded to mock 2.0.0 to match python3 unittest.mock features
fixed flake8 issues
implement safe JSON decode with oslo_serialization.jsonutils.dump_as_bytes()
implement safe unicode encode/decode with oslo_utils.encodeutils
heat: convert pub key file from bytes to unicode
pkg_resources returns raw bytes, in python3
we have to decode this to utf-8 unicode
so JSON can encode it for heat template
JIRA: YARDSTICK-452
Change-Id: Ib80dd1d0c0eb0592acd832b82f6a7f8f7c20bfda
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
The logging methods do string interpolation themselves
From the reference:
https://docs.python.org/2/library/logging.html#logging.Logger.debug
Logger.debug(msg, *args, **kwargs)
Logs a message with level DEBUG on this logger. The msg is the message format string, and the args are the arguments which are merged into msg using the string formatting operator. (Note that this means that you can use keywords in the format string, together with a single dictionary argument.)
There are two keyword arguments in kwargs which are inspected: exc_info which, if it does not evaluate as false, causes exception information to be added to the logging message. If an exception tuple (in the format returned by sys.exc_info()) is provided, it is used; otherwise, sys.exc_info() is called to get the exception informatio
The reason logging does string interpolation itselfs is to implement deferred interpolation.
String interpolation involves evaluating arguments, so it can introduce significant computation. The logging module tries to be smart about deferring interpolation until the last possible moment.
The logging methods check isEnabledFor for the log level and won't interpolate if the level is not enabled.
https://github.com/python/cpython/blob/2.7/Lib/logging/__init__.py#L1178
def warning(self, msg, *args, **kwargs):
if self.isEnabledFor(WARNING):
self._log(WARNING, msg, args, **kwargs)
logging actually waits to interpolate the string in LogRecord.getMessage()
https://github.com/python/cpython/blob/2.7/Lib/logging/__init__.py#L328
if self.args:
msg = msg % self.args
Change-Id: Ie09efe0a66881e19bd8119caa376075e605627a2
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
Changed to rally copyright as lots of concepts and code have
been reused.
Change-Id: Id850b94c9ad05a075614870b293456f2d5fb6e5f
Signed-off-by: Jo¶rgen Karlsson <jorgen.w.karlsson@ericsson.com>
|
|
Change-Id: I14f21092f5e97abf0629a92a27062846a6d3130b
JIRA:-
Signed-off-by: Jo¶rgen Karlsson <jorgen.w.karlsson@ericsson.com>
|
|
This change adds the possibility to run scenarios as "background
tasks".
Background scenarios/tasks:
- are started before all "normal scenarios"
- runs in parallel with "normal scenarios"
- terminates when all "normal scenarios" have completed
their tasks
They are intended as a way to perform background tasks, e.g. collect
data such as cpuload etc, in parallel with the execution of normal
benchmarking scenarios.
Note that we already have the 'run_in_parallel' attribute but
this attribute has a couple of issues and do not solve all the
uses cases.
Change-Id: I9c5230bfdbbb66030f57b658ce1db87ff2c2d62b
Signed-off-by: Jo¶rgen Karlsson <jorgen.w.karlsson@ericsson.com>
|
|
Heat context code refactor to cater for the evolution of the
Yardstick framework.
Refactor runner_cfg host/target info handle, as specified at
https://etherpad.opnfv.org/p/yardstick_framework
step 4. Get general Context info (use Context.get).
Before this refactor host and target vm must have the same user name
and ssh key, that is not general enough for later extension.
test_case.yaml do NOT need to change.
JIRA: YARDSTICK-168
Change-Id: I5cfe868f3c6f633214ef550bc9676fe1de0709db
Signed-off-by: QiLiang <liangqi1@huawei.com>
|
|
Execute a sample task file from Yardstick, push the test results
to MongodB provided by Releng using the common result api
provided by Functest.
Usage:
0) install yardstick
1) config yardstick
mkdir /etc/yardstick
cat << EOF >> /etc/yardstick/yardstick.conf
[DEFAULT]
debug = True
dispatcher = http
[dispatcher_http]
timeout = 5
target = http://213.77.62.197/results
EOF
2) run test
yardstick task start sample/fio.yaml
3) fetch result from remote result_collection_api
curl "http://213.77.62.197/results?case=Fio&installer=compass"
JIRA: YARDSTICK-132
Change-Id: I0996c6487c1900704380feb895555057a3f184e9
Signed-off-by: QiLiang <liangqi1@huawei.com>
|
|
JIRA:YARDSTICK-100
Change-Id: I1986b5e443abf186ef9c0235b66ada26c8574af1
Signed-off-by: wym_libra <yimin.wang@huawei.com>
|
|
Use openstack library oslo_config for parsing configuration options
from the command line and configuration files.
Refer http://docs.openstack.org/developer/oslo.config/ or rally
source code for more info on oslo_config library usage.
This patch is initially for test result dispatcher configuration,
but it is very general to use.
Usage:
0) install yardstick
1) mkdir /etc/yardstick
2) cp <repo_root_dir>/etc/yardstick/yardstick.conf.sample \
/etc/yardstick/yardstick.conf
3) edit /etc/yardstick/yardstick.conf
4) run `yardstick task start xxx` cmd
JIRA: YARDSTICK-61
Change-Id: I01677ef6e9ab7c1975aa193799195e850da73478
Signed-off-by: QiLiang <liangqi1@huawei.com>
|
|
Note: this commit replaces:
https://gerrit.opnfv.org/gerrit/#/c/976/8
Adjusts the JSON output of the runners to follow a different structure,
laid out below. It is based upon the patch above but is not using the
output manager.
The purpose is to provide a unified basic layout (as already existed),
while making long data series much less repetitive and more space
efficient.
OUTPUT FORMAT:
------------------------------------------------------------------------
RUNNER PREP - printed exactly once per runner per scenario.
Runner MUST print this before sending any RUNNER DATA output
{
runner_id: <int>
scenario_cfg: {
<scenario and runner config>
}
}
where
runner_id: ID of the runner sending this block
scenario_cfg: scenario and runner configuration
------------------------------------------------------------------------
RUNNER DATA
runner may print any number of these AFTER having printed a RUNNER PREP
{
runner_id: <int>
benchmark: {
<measurements>
}
}
------------------------------------------------------------------------
The runner_id currently is not unique across runners as it is assigned
by noting the runner process id in the underlying operating system.
A possible improvement would be to assign runner_id an UUID value
according to RFC 4122 (e.g. uuid.uuid4() in python).
------------------------------------------------------------------------
Other changes/cleanups in this patch:
- Removed the context argument from _worker_process as it was
redundant. It contained a dictionary with the runner configuration
but the same dictionary was already in included in the scenario_args argument.
- For clarity renamed scenario_args to scenario_cfg. scenario_cfg was
the original name used in task.py and it changed name across function calls.
Change-Id: I17d96f37c7d3e24b0747d23fcad7509fa949d662
JIRA: YARDSTICK-59
Signed-off-by: Jo¶rgen Karlsson <jorgen.w.karlsson@ericsson.com>
|
|
This patch is the initial implementation of DB result storage.
Having implemented a dispathcer which enable user select different ways
to store test results according to different requirements. This patch
can support not only local file storage, but also remote storage by
using http request(it will call common-db-api when available). Later,
local DB sotrage will be supported.
This patch is raw and simple, which is implemented with reference to
openstack ceilometer.
Any comment is welcome.
JIRA: YARDSTICK-61
Change-Id: Icaf8369edfab5d05f0819eb02d5b05dc8a04d69d
Signed-off-by: QiLiang <liangqi1@huawei.com>
|
|
The output of scenarios will be appended to the yardstick.out file.
JIRA: YARDSTICK-45
Change-Id: I185c6d2a8a534c8bb2b731bb84c47bdf4bad4427
Signed-off-by: panghao1 <shamrock.pang@huawei.com>
|
|
pre-start and post-stop intention is to be used to gather
information about the target system.
single-shot and periodic-action intention is to perform
actions on the infrastructure or cloud resources. For example
server live migration or network interface down.
Example of what can be added in the runner section:
pre-start-action:
command: "heat stack-show demo"
periodic-action:
interval: 10
command: "ifconfig vboxnet1"
single-shot-action:
after: 30
command: "nova show goofy.demo"
post-stop-action:
command: "nova list"
pre-start and post-stop data are added into the output file.
periodic and single-shot are not because that would interfere with
the actual sampled data. Besides the intention is not to log statistics
but do things with the infrastructure such as server live migration.
TODO: add sections to the output file, something like pre, data & post
JIRA: YARDSTICK-46
Change-Id: Ia059813fb74733f86368aea9c7a20e5afb71d228
Signed-off-by: Hans Feldt <hans.feldt@ericsson.com>
|
|
Example usage and output:
$ yardstick runner list
+------------------------------------------------------------------------------+
| Type | Description
+------------------------------------------------------------------------------+
| Duration | Run a scenario for a certain amount of time
| Arithmetic | Run a scenario arithmetically stepping an input value
| Constant | Run a scenario a certain number of times
+------------------------------------------------------------------------------+
$ yardstick runner show Duration
Run a scenario for a certain amount of time
If the scenario ends before the time has elapsed, it will be started again.
Parameters
duration - amount of time the scenario will be run for
type: int
unit: seconds
default: 1 sec
interval - time to wait between each scenario invocation
type: int
unit: seconds
default: 1 sec
$ yardstick scenario list
+------------------------------------------------------------------------------+
| Type | Description
+------------------------------------------------------------------------------+
| Iperf3 | Execute iperf3 between two hosts
| Pktgen | Execute pktgen between two hosts
| Ping | Execute ping between two hosts
+------------------------------------------------------------------------------+
$ yardstick scenario show Iperf3
Execute iperf3 between two hosts
By default TCP is used but UDP can also be configured.
For more info see http://software.es.net/iperf
Parameters
bytes - number of bytes to transmit
only valid with a non duration runner, mutually exclusive with blockcount
type: int
unit: bytes
default: 56
udp - use UDP rather than TCP
type: bool
unit: na
default: false
nodelay - set TCP no delay, disabling Nagle's Algorithm
type: bool
unit: na
default: false
blockcount - number of blocks (packets) to transmit,
only valid with a non duration runner, mutually exclusive with bytes
type: int
unit: bytes
default: -
JIRA: -
Change-Id: If218e129a30af7e20792190003c214677e732252
Signed-off-by: Hans Feldt <hans.feldt@ericsson.com>
|
|
tested by changing SLA action to assert and lower rtt, yardstick
command should exit non zero
Change-Id: I2dd091941fb4359add849f218cacc04f364142cd
JIRA: YARDSTICK-25
Signed-off-by: Hans Feldt <hans.feldt@ericsson.com>
|
|
The "duration" runner will run a test for an amount of time.
The "arithmetic" runner will increase an input value of the test for
every run until a limit is reached.
Change-Id: I31c9864604110ce3f5d19ec110144d1c886c7620
JIRA: -
Signed-off-by: Hans Feldt <hans.feldt@ericsson.com>
|