| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
weird error
E AddressValueError: '10.20.0.0/15' does not appear to be an IPv4 or IPv6 network. Did you pass in a bytes (str in Python 2) instead of a unicode object?
I guess we need to convert the stack.outputs mock to unicode
FAILED
tests/unit/benchmark/contexts/test_heat.py:137 (HeatContextTestCase.test_add_server_port)
self = <tests.unit.benchmark.contexts.test_heat.HeatContextTestCase testMethod=test_add_server_port>
def test_add_server_port(self):
network1 = mock.MagicMock()
network1.vld_id = 'vld111'
network2 = mock.MagicMock()
network2.vld_id = 'vld777'
self.test_context.name = 'foo'
self.test_context.stack = mock.MagicMock()
self.test_context.networks = {
'a': network1,
'c': network2,
}
self.test_context.stack.outputs = {
'b': '10.20.30.45',
'b-subnet_id': 1,
'foo-a-subnet-cidr': '10.20.0.0/15',
'foo-a-subnet-gateway_ip': '10.20.30.1',
'b-mac_address': '00:01',
'b-device_id': 'dev21',
'b-network_id': 'net789',
'd': '40.30.20.15',
'd-subnet_id': 2,
'foo-c-subnet-cidr': '40.30.0.0/18',
'foo-c-subnet-gateway_ip': '40.30.20.254',
'd-mac_address': '00:10',
'd-device_id': 'dev43',
'd-network_id': 'net987',
}
server = mock.MagicMock()
server.ports = OrderedDict([
('a', {'stack_name': 'b'}),
('c', {'stack_name': 'd'}),
])
expected = {
"private_ip": '10.20.30.45',
"subnet_id": 1,
"subnet_cidr": '10.20.0.0/15',
"network": '10.20.0.0',
"netmask": '255.254.0.0',
"gateway_ip": '10.20.30.1',
"mac_address": '00:01',
"device_id": 'dev21',
"network_id": 'net789',
"network_name": 'a',
"local_mac": '00:01',
"local_ip": '10.20.30.45',
"vld_id": 'vld111',
}
> self.test_context.add_server_port(server)
tests/unit/benchmark/contexts/test_heat.py:186:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
yardstick/benchmark/contexts/heat.py:307: in add_server_port
network_name, port['stack_name'], self.stack.outputs)
yardstick/benchmark/contexts/heat.py:315: in make_interface_dict
subnet_ip = ipaddress.ip_network(subnet_cidr)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
address = '10.20.0.0/15', strict = True
def ip_network(address, strict=True):
"""Take an IP string/int and return an object of the correct type.
Args:
address: A string or integer, the IP network. Either IPv4 or
IPv6 networks may be supplied; integers less than 2**32 will
be considered to be IPv4 by default.
Returns:
An IPv4Network or IPv6Network object.
Raises:
ValueError: if the string passed isn't either a v4 or a v6
address. Or if the network has host bits set.
"""
try:
return IPv4Network(address, strict)
except (AddressValueError, NetmaskValueError):
pass
try:
return IPv6Network(address, strict)
except (AddressValueError, NetmaskValueError):
pass
if isinstance(address, bytes):
raise AddressValueError(
'%r does not appear to be an IPv4 or IPv6 network. '
'Did you pass in a bytes (str in Python 2) instead of'
> ' a unicode object?' % address)
E AddressValueError: '10.20.0.0/15' does not appear to be an IPv4 or IPv6 network. Did you pass in a bytes (str in Python 2) instead of a unicode object?
../../yardstick/yardstick_venv/lib/python2.7/site-packages/ipaddress.py:199: AddressValueError
Change-Id: Ie3b087a26a054203573eaa9b13c3e90152bba6a9
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
we need to know which network each port is connected to
so we can find VLAN or VXLAN ID.
To do this we implement a new method for Contexts,
Context.get_network(). This method is similar to
Context.get_server(), it searches for a given
network name in all the contexts.
From this we generate a context_cfg["networks"]
dict that stores all the network info for the nodes
in the scenario.
Then when we generate the topology for VNFD, we can
lookup a given network by the vld_id and get the
network_type, segmentation_id, etc.
Then if we need to for example generated
traffic on a given VLAN or VXLAN, we have this
info available.
Define default nd_route_tbl for ACL VNF
we need default empty nd_route_tbl for IPv6 route.
Change-Id: I9f9cfbd6acabeb4ae4675ca7354390efa57b29e7
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Edward MacGillivray <edward.s.macgillivray@intel.com>
|
|
First we add mac_address, subnet_cidr to Heat template outputs
Then we convert those into a form for NSB and add vld_id.
NSB also requires PCI Bus ID, kernel driver
and dpdk_port_num. We get this by ssh-ing
into instance and dumping sysfs
We also need to fix allow for ssh key auth,
and implement relative path file loading
so NSB can find all its YAML files
JIRA: YARDSTICK-580
Change history:
don't hide heat create tracebacks we need tracebacks for debug
vnf_generic: add task_path to scenario so we can load relative paths
for vnf_generic we want to be able to load yaml relative to the
task path
For example:
traffic_profile: ../../traffic_profiles/fixed.yaml
topology: ping_tg_topology.yaml # TODO: look in relative path where the tc.yaml is found
These need to be relative to samples/vnf_samples/nsut/ping/tc_ping_heat_context.yaml
Add a scenario["task_path"] entry
heat: log actual exception
vnf_generic: replace list with set and iterate over values()
some general refactors to remove redundact lookups and
type conversions
heat: provide mac_address, device_id and network_id from outputs
We may need more information to dynamically
determine test topology.
Towards this end return more info in the heat template.
We can return mac_address, device_id and network_id.
Once we have this info we can add it to the context_cfg
as an interfaces dict.
add sample vnf ping multi-network test
this test requires 3 network, one for mgmt
and the other two for NSB traffic tests
We have to make sure we don't use DPDK
on mgmt interface because DPDK unbinds
the driver
heat: convert networks to OrderedDict
so we can lookups networks as well as
iterate over them in consisitent order
heat: and vld_id to networks for vnf_generic
vnf_generic uses vld_id Virtual Link Descriptor ID
to identify interfaces
Add the key to the networks dict
and store in Networks object
implement relative path file loading in vnf_generic
in multiple places we need to load a file
relative to the task path, so add
open_relative_file_path
and modify load_vnf_model to include the scenario_cfg
parameter so we have access to task_path
DRAFT: heat timeout support
Heat stack in CI job failed due to some Nova issue.
But then apparently yardstick kept running and took 180mins to timeout
https://build.opnfv.org/ci/view/bottlenecks/job/bottlenecks-compass-posca_stress_ping-baremetal-daily-master/16/console
We can add a Heat create timeout and fail faster if there is an error.
The question is how long should we wait for a Heat stack to deploy. We
can set a default and allow override in the heat context config, if
users make complicated stacks
heat: get netmask and gateway from heat outputs
we have do some tricky business with finding
the subnet cidr and converting it into netmask
vnf_generic: get vpci, driver and dpdk_port_num
use a big old find command to dump all the sysfs
netdev info nicely. This was re-used from autotest FCoE tests.
r"""find /sys/devices/pci* -type d -name net -exec sh -c '{ grep -sH ^ \
+$1/ifindex $1/address $1/operstate $1/device/vendor $1/device/device \
+$1/device/subsystem_vendor $1/device/subsystem_device ; \
+printf "%s/driver:" $1 ; basename $(readlink -s $1/device/driver); } \
+' sh \{\}/* \;
This finds all PCI devices that are network devices, then
dumps all the relevant info using /bin/sh.
Then we parse this into a 'netdevs' dict inside the node_dict
and also convert into VNF fields we need.
vnf_generic: set node name for kpis
node is a dict, so we have to use node_name
vnfdgen: we CANNOT use TaskTemplate.render
because it does not allow for missing variables, we need to allow
password for key_filename to be undefined
remove default ssh password hack, once rendering is fixed
add new example tc_external_ping_heat_context
Change-Id: If1fe0c1a2ab0a5be17e40790a66f28f706fa44d6
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Edward MacGillivray <edward.s.macgillivray@intel.com>
|
|
JIRA: YARDSTICK-582
Create a customizable flavor via heat context. All heat parameters
are configurable including Core Affinity. The default flavor name
is XXXX-flavor where XXXX is stackname. Flavor attributes are taken
from the heat context file. If a flavor attribute is not used it
takes default attribute value. If flavor name is not specified it
uses the server name + "-flavor" or stack-name + "-flavor".
Compute node specific attributes are configurable via "extra_specs"
attribute. See
https://docs.openstack.org/admin-guide/compute-flavors.html for
details.
Change-Id: If4015970b889b0b95bfa8eba9491ebf31e92f2c7
Signed-off-by: DanielMartinBuckley <daniel.m.buckley@intel.com>
|
|
A generic provider network solution is introduced. To identify whether a network specified in the test case is a provider network new attributes are introduced in the test case network section:
networks:
test-net:
cidr: '192.168.1.0/24'
provider: "sriov"
physical_network: 'physnet1'
If the "provider" attribute is present, the network is an existing provider network. If the value is "sriov", binding:vnic_type=direct is added to the interface in the heat deployment template. In orchestrator/heat.py, the interface creating functions are given a new parameter that tells if the network in use is a provider network. The benchmark/contexts/model.py is changed to store the value of the provider attribute from the test case and function calls to port creation is updated with the provider parameter. The same change is made in contexts/heat.py as well. Also calls for creating a new tenant network is replaced for creating a new provider network if the provider attribute is present.
Update-1: Change test_model.py
Update-2: Per comment, change comment style to """"
Update-3: Change test_heat.py
Update-4: Add unit test cases to pass coverage test
Update-5: Add SRIOV provider network example in opnfv_yardstick_tc008.yaml
Update-6: Per comment, remove empty line in orchestrator/test_heat.py
Update-7: Per comment, change comment lines in orchestrator/test_heat.py
Update-8: Add more unit test cases to pass coverage test
Update-9: Change to create SRIOV provider network on the fly so as to support co-current test runs
Update-10: Per comment, init physical_network to 'physnet1'
Change-Id: I76004c4fcc9bffcfd8ed021fd647e0cecb346ef4
JIRA: YARDSTICK-612
Signed-off-by: Jing Zhang <jing.c.zhang@nokia.com>
|
|
JIRA: YARDSTICK-566
Current Heat context support affinity and availability arguments
but not support affinity and anti-affinity.
Enhance Heat context to support affinity and anti-affinity:
1. can create heat server group with affinity/anti-affinity
2. each server could be specified which server group they are in
Change-Id: I46e7376fd116c6e109cb5dcb1c168460918e6d43
Signed-off-by: rexlee8776 <limingjiang@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>
|
|
JIRA: YARDSTICK-527
This work is to support yardstick parallel tasks in the future.
Currently, the RSA key we generated and used to access the VM is named
'yardstick_key'.
If more than two tasks are running paralleled, the later 'yardstick_key' will
cover the former.
We want associate an uuid to identify differnets for each tasks. So the key
files won't conflict.
The first 8 digits will be used, as there is no need to used a full-length uuid.
Change-Id: If8eaf47ae527cf9b3bd50f37ab3051fbdccf5f03
Signed-off-by: JingLu5 <lvjing5@huawei.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>
|
|
Heat context code refactor to cater for the evolution of the
Yardstick framework.
At test_case.yaml context segment add "type" to indicate the
context type, see samples/ping-heat-context.yaml for an example.
And the default context type is Heat, so the existing yaml file
do not need to change.
JIRA: YARDSTICK-168
Change-Id: Ida0ce12c17cd9b88d7acfb4c9eb1ac6986394b38
Signed-off-by: QiLiang <liangqi1@huawei.com>
|
Ross Brattain
Edward MacGillivray
DanielMartinBuckley
Jing Zhang
rexlee8776
JingLu5
QiLiang