aboutsummaryrefslogtreecommitdiffstats
path: root/yardstick/benchmark/runners/duration.py
AgeCommit message (Collapse)AuthorFilesLines
2018-10-02NSB PROX NFVi Test does not stop after reaching expected precisionDanielMartinBuckley1-1/+2
JIRA: YARDSTICK-1419 When using prox_binsearch algorithm, a binary search is performed, increasing lower bound when step was successful and decreasing upper bound when the step was a failure. This runs until the test_precision (as specified in the traffic profile) is reached. When the test precision is reached, the test is not completed until the runner duration is reached. As runner duration is usually high (e.g. 1800sec), the tests take much too long to execute. This makes it difficult to create test suites. Change-Id: I6cc503a09fb534a556c61c805e6df4786bb8cc4b Signed-off-by: Daniel Martin Buckley <daniel.m.buckley@intel.com>
2018-07-05[Bug fix] Execute teardown if SLA is set to "assert"Dimitrios Markou1-0/+1
In Duration runner if SLA is set to "assert" and a SLAValidationError happens then a teardown is needed to avoid garbages in the environment. JIRA: YARDSTICK-1291 Change-Id: I9056b0da3e7e496171ed42430ffc340b5c68f108 Signed-off-by: Dimitrios Markou <mardim@intracom-telecom.com>
2018-06-15Convert SLA asserts to raisesMiikka Koistinen1-3/+4
This commit converts Python assertions to a custom exception in all places where SLA validation is checked with an assertion. This commit also fixes all emerged pylint errors. JIRA: YARDSTICK-966 Change-Id: If771ed03b2cbc0a43a57fcfb9293f18740b3ff80 Signed-off-by: Miikka Koistinen <miikka.koistinen@nokia.com>
2018-03-21Add "Scenario" class wait methods for runnersRodolfo Alonso Hernandez1-2/+4
"Duration" and "Iteration" runners execute a passive wait during the execution of the work process. This wait time is done at the end of the scenario "run" method execution. This patch adds a pre-run and post-run wait period, which will depends on the Scenario executed. The wait time will be always the same, but the execution order (pre-wait time, run method, post-wait time) will depends on the Scenario. By default, any Scenario will execute the "run" method and them will wait the specified time. NetworkServicesTestCase Scenario will wait the specified time and them will execute the "run" method to retrieve the KPIs. JIRA: YARDSTICK-1067 Change-Id: I6ad6bfc6978815b6b2d4df63f2ac2f8815fb5b8a Signed-off-by: Rodolfo Alonso Hernandez <rodolfo.alonso.hernandez@intel.com>
2017-10-03NSB PROX test hang fixesRoss Brattain1-0/+2
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>
2017-10-02runners: add timeout to queue putRoss Brattain1-2/+7
we don't want to block the test waiting to put KPIs Add moderate timeout. In case we do timeout, it doesn't matter if we drop intermitten KPIs Change-Id: I049c785355993e6b286748a5c897d54dd2923dc9 Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
2017-10-02drain runner queue and undo cancel_join_threadRoss Brattain1-5/+3
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>
2017-10-01duration runner: add teardown and cancel all queue join threadsRoss Brattain1-5/+20
calculate timeout once catch exceptions in benchmark.teardown() 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: If7b904a060b9ed68b7def78c851deefca4e0de5d Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
2017-09-14improve logging, clear using printrexlee87761-2/+3
Change-Id: I744353f631cf1771d75f750543e8612f81be71ee Signed-off-by: rexlee8776 <limingjiang@huawei.com>
2017-06-22Yardstick output format unifiedchenjiankun1-8/+1
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>
2017-05-26Pass parameters between scenarioschenjiankun1-3/+6
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>
2017-01-16Use """ to replace ''' in docstringchenjiankun1-4/+4
JIRA: YARDSTICK-525 For consistency, we always use """triple double quotes""" around docstrings. Change-Id: I47a20bbd8b55bc544b4841ea4006929af0a044ac Signed-off-by: chenjiankun <chenjiankun1@huawei.com>
2017-01-12Add support for Python 3Ross Brattain1-0/+1
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>
2016-11-30switch logging to proper usageRoss Brattain1-3/+3
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>
2016-03-14Change copyright for runners.Jo¶rgen Karlsson1-7/+16
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>
2015-12-15Add run_in_background attribute to scenariosJo¶rgen Karlsson1-3/+6
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>
2015-10-27Heat context code refactor part 2QiLiang1-6/+7
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>
2015-10-22Update sla check for scenarioshoujingwen1-1/+1
This patch modify the question that SLA check result is not complete. JIRA: YARDSTICK-172 Change-Id: I10438390baee92caf00dbfcdbdb833823ff8ce31 Signed-off-by: houjingwen <houjingwen@huawei.com>
2015-09-22Structure output and make it less redundantJo¶rgen Karlsson1-17/+21
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>
2015-06-29Add support to list and show runners & scenariosHans Feldt1-1/+14
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>
2015-05-26add setup/teardown to scenario base class and runnersHans Feldt1-4/+8
Prepare for "service type" of scenarios that e.g. needs to start a service in setup and shut it down in teardown. In the runners, instantiation of the scenario is moved after the "worker START" log to get a more logical sequence logged. Change-Id: Idfaf5bb396eab9261e820291885b5a1dbc32f71e JIRA: - Signed-off-by: Hans Feldt <hans.feldt@ericsson.com>
2015-05-21add package runners and a few runnersHans Feldt1-0/+95
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>