Age | Commit message (Collapse) | Author | Files | Lines |
|
Users would like to ensure placement of VMs on specific compute nodes so
that the measurements are meaningful. Examples: Measure network
performance in different scenarios (VMs in same host, in different
hosts, across fabric, across tenants)
Example:
context:
name: yardstick
placement_groups:
pgrp1:
policy: "availability"
servers:
tg_0:
floating_ip: true
placement: "pgrp1"
availability_zone: "zone2"
vnf_0:
floating_ip: true
placement: "pgrp1"
availability_zone: "zone1"
Change-Id: I28a757c25ae3f5b3571ab3edd82d51ceba32c302
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
JIRA: YARDSTICK-757
Some test scenarios require VM with specific vnic type.
This work is about supporting using different vnic types in heat type context.
context:
name: demo
image: cirros-0.3.5
flavor: yardstick-flavor
user: cirros
placement_groups:
pgrp1:
policy: "availability"
servers:
athena:
floating_ip: true
placement: "pgrp1"
ares:
placement: "pgrp1"
networks:
test:
cidr: '10.0.1.0/24'
vnic_type: "normal"
Change-Id: Ia229fda72f47b04288ea107e2d58fd3e8ac91dd9
Signed-off-by: JingLu5 <lvjing5@huawei.com>
|
|
xe0:
cidr: '10.0.2.0/24'
vld_id: public
allowed_address_pairs:
- ip_address:
'0.0.0.0/0'
xe1:
cidr: '10.0.3.0/24'
vld_id: private
allowed_address_pairs:
- ip_address:
'0.0.0.0/0'
We need to disable gateways on data plane interfaces
With TGs and VFNs we probably don't need gateway on data interfaces
Change-Id: I276a7d591a0a3ff03877c4f525303fc2874de683
Signed-off-by: Ross Brattain <ross.b.brattain@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>
|
|
remove redundnant parens
replace type with isinstance
fix import order
Change-Id: I0407cbbf6993290f392f17c398827603b5bc1ebd
Signed-off-by: Ross Brattain <ross.b.brattain@intel.com>
|
|
We had code to support adding user_data but the
Server model was not connected.
The string formatting of the user_data is left
as an exercise for the reader.
Change-Id: I298657b93de67e19436bca616b119df636dacce2
Signed-off-by: Ross Brattain <ross.b.brattain@intel.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>
|
|
In Heat Liberty release OS::Nova::Server will always use the user
pre-configured in the image (e.g. "fedora" for stock Fedora cloud
images, "ubuntu" for stock Ubuntu cloud images, "cloud-user" for
stock CentOS cloud images etc)
Change all ec2-user -> ubuntu
Add admin-user in Heat model for backwards compatibility.
Refer below links for detalis:
https://etherpad.opnfv.org/p/yardstick_release_b_troubleshooting
https://github.com/openstack/heat/commit/e423bec7f10b0f5d07f05d195b3b7860f6bceb00
http://blog.scottlowe.org/2015/04/23/ubuntu-openstack-heat-cloud-init/
JIRA: -
Change-Id: I6b8b2b21daf113a3a86aee1126b0c3e74737ef4f
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>
|