aboutsummaryrefslogtreecommitdiffstats
path: root/yardstick/benchmark/scenarios/availability/monitor/basemonitor.py
AgeCommit message (Collapse)AuthorFilesLines
2018-05-08Fix log typos in benchmark/scenarios/availabilityMiikka Koistinen1-1/+1
This commit fixes multiple log message typos and all the emerged pylint errors. MonitorProcess/MonitorOpenstackCmd.verify_SLA() repeat already logged information, so these prints are removed. JIRA: YARDSTICK-1145 Change-Id: Ifef26e4b4ff7766089caec24785511969c2d663e Signed-off-by: Miikka Koistinen <miikka.koistinen@nokia.com>
2017-10-04Add intermediate variables for attacker,monitor,result_checkerqiujuan1-0/+1
JIRA: YARDSTICK-790 Change-Id: I6bb36c98b8673155d3142fc54cfb39315d5ce613 Signed-off-by: qiujuan <juan_qiu@tongji.edu.cn>
2017-10-02drain runner queue and undo cancel_join_threadRoss Brattain1-1/+0
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-01cancel all queue join threadsRoss Brattain1-0/+1
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>
2017-09-01Bugfix: ha test case criteria pass when sla not passrexlee87761-2/+13
ha test cases didn't store moniter info and report fail when sla didn't pass Change-Id: I0e5637e37a66e1bf03b47fe09d17e0a1acfa11c1 Signed-off-by: rexlee8776 <limingjiang@huawei.com>
2017-08-15YAML fixesRoss Brattain1-2/+3
There are multiple issues wiht YAML loading. 1. Jinja2 renders None values as a string 'None'. This is not valid YAML we need to render None values to '~' or 'null' which is the native YAML None value. 2. Jinja2 renders dict and lists that contain unicode with u'foo' values. This is not value YAML syntax. Because we are serializing dict and lists into YAML, we need to encode them as valid YAML. We can override Jinja2 finalize to use yaml.dump to dump inline YAML. We use yaml.safe_dump(elem, default_flow_style=True).replace('\n', '') to generate valid single-line YAML dict and list values. But this problem highlights the general difficulties with templating and loading files. We could avoid this Python->Jinja2->YAML->Python issue by directly injecting the list or dict after the YAML is loaded. I'm not sure of the real utility of these templates. 3. On Python 2 YAML loader is rendering all strings as unicode. This does not work for Trex because Trex is broken and badly coded. Trex does type checking against str() which is different for Python 2 and Python 3. The default YAML loader will return native string types, str() or unicode() for Python 2 and Python 3 respectively. The bad Trex codes is in convert_val: https://github.com/cisco-system-traffic-generator/trex-core/blob/master/scripts/automation/trex_control_plane/stl/trex_stl_lib/trex_stl_packet_builder_scapy.py#L674 def convert_val (val): if is_integer(val): return val if type(val) == str: return ipv4_str_to_num (is_valid_ipv4(val)) raise CTRexPacketBuildException(-11,("init val invalid %s ") % val ); This code is doing type(val) == str. This is bad and broken. We can't fix Trex, so we have to render all strings as native str() types The bug here was that the Heat template loader template_format.py was overriding the global YAML loader to always return unicode. We don't want this global override. To fix this we have to use local subclasses of the yaml.SafeLoader class. But in order to dynamically subclass from CSafeLoader or SafeLoader we have to use the type() builtin to define a new class at runtime. Once we have new classes defined, we can safely isolate different YAML constructors and return unicode or not depending on the case. To be consistent we implement a new yaml_loader.py module to centralize all non-Heat template yaml loading to ensure correct uncode/str conversion Change-Id: Iebf9cf78fbda390977c390436b0869e7bbf503eb Signed-off-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
2017-08-01replace yaml.load with yaml.safe_loadRoss Brattain1-1/+1
yaml.safe_load is safer, obviously. anteater will check for this template_format use specialized constructor based on yaml.SafeLoader JIRA: YARDSTICK-760 Change-Id: Ia3b0b3aa0765385a0ee472a4d83f49d424b5a77f Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
2017-05-27Imporve monitor_process pass criteriaJingLu51-3/+6
JIRA: YARDSTICK-660 The monitor func()'s criteria in the monitor_process.py now is whether at least one process of the specific controller node service is recovered. But in reality is more resonable to use whether processes have been recoverd to it's original amount. This patch is aiming at improving the isssue Change-Id: I950ce2a89555801b96092735b0d670e892049927 Signed-off-by: JingLu5 <lvjing5@huawei.com>
2017-04-12Add a new monitor type: MultiMonitor that can run any number of other ↵LiHuan1-0/+10
monitors at the same time. JIRA: YARDSTICK-397 Change-Id: Ic5cb79f0820029e306373abead1ea43fac9abee2 Signed-off-by: HuanLi <lihuansse@tongji.edu.cn>
2017-01-16Use """ to replace ''' in docstringchenjiankun1-1/+1
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-1/+3
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-06-30Creating a generic monitorlihuan1-1/+13
JIRA: YARDSTICK-274 Change-Id: Iac8c525b36b2778767177b17e6107866cc514e40 Signed-off-by: lihuan <lihuansse@tongji.edu.cn>
2016-01-10The secondi HA test case-shutdown controllerwym_libra1-31/+31
1) add "attacker_baremetal.py" for fault injection 2) modify the monitor to excute on remote node after ssh connection 3) move all shell scripts together JIRA: YARDSTICK-182 Change-Id: Ibb9dc908224ddb8b99a0140b75c1a046503f6dfb Signed-off-by: wym_libra <yimin.wang@huawei.com>
2016-01-10Rewrite the HA test case (2)wym_libra1-0/+140
idea: refact the Monitor class in old file "monitor.py" with the base class and sub-class. detail: 1) the BaseMonitor is the base class of other monitor 2) each monitor run in independent process 3) there are two monitor("openstack-cmd" and "process") for the first test case 4) MonitorMgr class used to manager monitor process JIRA: YARDSTICK-149 Change-Id: I2eede94481f740812212e6cb673d175b5f543c15 Signed-off-by: wym_libra <yimin.wang@huawei.com>