aboutsummaryrefslogtreecommitdiffstats
path: root/tests/unit/benchmark/scenarios/lib
AgeCommit message (Collapse)AuthorFilesLines
2017-08-21Merge "Add common openstack opertation scenarios: network"Jing Lu3-0/+102
2017-08-15YAML fixesRoss Brattain1-3/+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-11Merge "Add common openstack opertation scenarios: image & volume"Jing Lu4-0/+152
2017-08-11Add common openstack opertation scenarios: networkJingLu53-0/+102
JIRA: YARDSTICK-781 This patch adds some common openstack opertation scenarios Change-Id: I854fc435a5c951245a5997cd4e3e63c5162030af Signed-off-by: JingLu5 <lvjing5@huawei.com>
2017-08-11Add common openstack opertation scenarios: image & volumeJingLu54-0/+152
JIRA: YARDSTICK-781 This patch adds some common openstack opertation scenarios Change-Id: I3de7dbb30eaebac4feebcf07dd6a0d2bdcf428d9 Signed-off-by: JingLu5 <lvjing5@huawei.com>
2017-08-11Add common openstack opertation scenarios: flavor & serverJingLu54-0/+147
JIRA: YARDSTICK-781 This patch adds some common openstack opertation scenarios Change-Id: I9e84a8894fe9b9c1754a45a0ddfdf93739164b9a Signed-off-by: JingLu5 <lvjing5@huawei.com>
2017-07-26Test Case: OPNFV_YARDSTICK_TC023: VM availability during live migrationchenjiankun8-0/+443
JIRA: YARDSTICK-174 This live migration test case is based on share storage, default share storage is enabled. This test case will do some config work. And do live migration and calculate the migration time and downtime. Change-Id: I6601601edebdd0ac6434ba632b1eba9e9bd4fda0 Signed-off-by: chenjiankun <chenjiankun1@huawei.com>