Adds tests to verify [1] which allows operators to add vIOMMU devices to
their guests via flavor configuration. Tests do a basic smoke test that
creates a guest with the vIOMMU flavor requirements and confirms to
relevant XML element is present on the domain. Test also resizes a
standard guest to a flavor with vIOMMU, and confirms to XML is present.
Then revert and confirm the element is no longer present.
[1] https://blueprints.launchpad.net/nova/+spec/libvirt-viommu-device
Change-Id: I92c3538f985f0db0ef24ce2c49a797d3fcb69252
Add test coverage for bochs display device [1]. Bochs is considered a
safe and simplified alternative to use over VGA when UEFI is enabled.
Test creates an image with firmware type of UEFI and video model of
bochs. Boots guest and confirms the model is present.
[1] https://blueprints.launchpad.net/nova/+spec/add-bochs-display-device
Change-Id: I85f6fdda6a1c1042de2870a9d9f13f4cc6b32974
Apparently downstream CI can't handle the second
barbican-tempest-plugin entry. Make it conditional on the Pyton
version as well.
Change-Id: I2c34afe243a73912837b6fc7efdff21eacf920a0
This is downstream 16.2 CI leaking upstream, but
barbican-tempest-plugin started requiring tempest>=27.0 as of
1.7.0/238cdf1b8d. Downstream 16.2 CI is for train, and we cap tempest
to 26.0, probably because that's the last tempest release to support
train. Cap our barbican-tempest-plugin requirement on Python 3.6 to a
version that doesn't need newer Tempest.
Change-Id: I624952d8661e901ba11cf4bb5a20eb3b5c8df1d7
This only covers that happy path of the feature. We agreed that the
error paths are hard to cover here and we rely on the nova functional
test instead.
There are two new config options:
* [compute_feature_enable]stable_compute_uuid_supported defaulted to
False to skip the tests for old deployments not having the feature.
* [whitebox-nova-compute]state_path defaulted to /var/lib/nova, to allow
running the tests in deployments that are using a non default nova
state path configuration (like devstack)
The devstack plugin is modified to set [whitebox-nova-compute]state_path
according to the devstack nova configuration.
Change-Id: I520bd61b6ab479a36098586f7296822703a24fb0
The tempest config group name is compute-feature-enabled the python code
needs to use CONF.compute_feature_enabled to access that group. But the
test skipping message should point to the group config name instead of
the python variable name to avoid confusion
Change-Id: I5b852d9f8dbb9392329d82c70a1686f96628a5e8
Current implementation of NUMA Affinity SR-IOV tests run into an issue
when paired with Neutron test plugins designed to test OVS ports.
Neutron plugin creates ports based on network.port_vnic_type if that is
present otherwise it defaults to a virtualized port. Attach/Detach tests
on Neutron side will fail for older releases when paired with Whitebox
since it will attempt to create SR-IOV ports when attach/detach is not
supported.
Updating Whitebox to have its own plugin specific vnic configuration
that is used first otherwise it falls back to network.port_vnic_type.
Change-Id: Idee8bfc7867b3a818e75165ebbc927142d00bed2
For multi-rhel environments the container/service names are different
based on the RHEL version. Introduce the capacity to define the expected
container/service names for each of the compute nodes in a deployment.
Current compute yaml file follows the below format:
computerhel8-0.redhat.local:
services:
libvirt:
container_name: nova_libvirt
start_command: 'systemctl start tripleo_nova_libvirt'
stop_command: 'systemctl stop tripleo_nova_libvirt'
nova-compute:
container_name: nova_compute
config_path: '/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf'
start_command: 'systemctl start tripleo_nova_compute'
stop_command: 'systemctl stop tripleo_nova_compute'
compute-0.redhat.local:
services:
libvirt:
container_name: nova_virtqemud
start_command: 'systemctl start tripleo_nova_virtqemud'
stop_command: 'systemctl stop tripleo_nova_virtqemud'
nova-compute:
container_name: nova_compute
config_path: '/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf'
start_command: 'systemctl start tripleo_nova_compute'
stop_command: 'systemctl stop tripleo_nova_compute'
Also removed the unit test execution since they do not support this
latest change and do not feel the tests are adding any value to commit
validation at this time.
Change-Id: I98ac827feb4be77af9a482d8ce43d0f1d062e54d
Current (Train/16.x) deployments downstream come with a Undercloud
installed with pip 9. When installing paramiko it attempts to install
cyrptography 3.3 which needs pip 10 or greater to install. In the past
downstream has been installing whitebox into its own virtualenv and
upgrading the associated pip accordingly without any issues. Downstream
we are hoping to extend whitebox coverage to other test teams but their
current environment does not support virtualenv installation at this
time.
When using python3.6 cap the two paramiko dependencies (see below) that
require pip 10:
* cryptography<3.3
* bcrypt<3.2
This will allows the environment to continue using pip9 instead of
pip10+.
Change-Id: I947b3c1089d26f4f1e375290163ae16cb09473be
Set our dedicated-per-numa value to 3 in the job to leave some room
for excluding cpu0 (which is special) in the next patch. Also try to
determine the appropriate number of dedicated cpus per test server
for cpu pinning by choosing half the minimum available amount on any
compute node.
Change-Id: If0bfd74f7ea9c3cfc7c2f21a939445ccb09e501d
Since [1] Devstack has been setting really long service report
intervals, and a correspondingly long service down time threshold.
While that makes sense for "normal" CI, in whitebox we don't have
the load problems that "normal" CI has, while also simultaneously
restarting services and needing the API to reflect their status
changes fairly quickly. Revert to the old value of 10 for the service
report internal, and therefore 10 * 6 for the service down time
threshold.
[1] https://review.opendev.org/c/openstack/devstack/+/890439
Change-Id: I3e8a830f11e11eaa3592ee5354f071bf73dd3435
With the inclusion of the Mixed RHEL deployments Live Migration is only
supported from older to new hypervisors. Current SR-IOV live migration
tests migrate back and forth by default. Add the
compute_feature_enabled.live_migrate_back_and_forth to the SR-IOV live
migration tests so that when testing Mixed RHEL deployments tests stop
after initial live migration.
By default the flag is false so adding the configuration as True to
devstack if SR-IOV tests are ever enabled upstream.
Change-Id: I0b188a484dcefd846613d05fe4c49e710778a952
The vDPA change [1] updated how network names are referenced for the
SRIOVAttachAndDetach class. It was updated from self.sriov_network to
self.network. There were subsequent references within the class that
still use self.sriov_network. This commit adjusts those references to
now use self.network.
[1] f7104a681d
Change-Id: If95e963e1a4e1d4ed592991b52c045b5fb92d2aa
To update that created a vlan ID parameter for SR-IOV (sriov_vlan_id)
[1], introduces the parameter as an int. When checking the vlan tag in
the guest it will return as a str causing the check to fail e.g.:
"testtools.matchers._impl.MismatchError: 2000 != '2000': Interface should have have vlan tag 2000 but instead it is tagged with 2000"
Casting the vlan tag found in the XML as an int to ensure the check
matches.
[1] f7104a681d
Change-Id: I62f519db8709c23824a0fee1a6ce63ab3bf1f9e2
Previously we had copy-pasted barbican client code into our own in
order to access secrets. If we install the barbican-tempest-plugin, we
can use their client directly, as explained in [1].
[1] https://docs.openstack.org/tempest/latest/plugins/plugin.html#service-clients
Change-Id: Iccbeef049af5e3a913d7ce56cd29f7dc66517532
This commit will add tests to cover vTPM device support for instances.
The vTPM device allows storing secrets at instance level and its managed
by the Barbican backend.
The _vptm_server_creation_check helper method is used to create server
with specific vtpm version and model and assert that it is configured as
needed from the instance xml.
The test_create_server_with_vtpm_tis method will verify creation of
instance with tpm-tis model and supported version 2.0.
Similarly, test_create_server_with_vtpm_crb will verify creation of
instance with tpm-crb model and supported version 2.0.
In addition the Barbican client service was leveraged from the barbican
tempest plugin [1]. This is to allow the vTPM test to communicate with
the barbican client, confirm the secret key found in the guest domain is
present in the client, the key is active, and the keys description
accuratly describes its purpose is vTPM for the guest. Example reply
from barbican below:
{'algorithm': None,
'bit_length': None,
'content_types': {'default': 'application/octet-stream'},
'created': '2021-10-13T18:17:52',
'creator_id': '4b1cc6071236438c881f9da54657468f',
'expiration': None,
'mode': None,
'name': 'vTPM secret for instance b537c0df-0e39-4af8-94b3-04bcc8262f20',
'secret_ref': 'http://192.168.24.3:9311/v1/secrets/13a9ae5e-5187-4c0f-acde-b2cda06ae00c',
'secret_type': 'passphrase',
'status': 'ACTIVE',
'updated': '2021-10-13T18:17:52'}
[1] https://github.com/openstack/barbican-tempest-plugin
Related to:
https://review.opendev.org/c/openstack/nova/+/631363/https://review.opendev.org/c/openstack/glance/+/633256/https://bugzilla.redhat.com/show_bug.cgi?id=1782128
Change-Id: I7b1a1306beb871a9294884116f6430ead91ce601
We want to run our vTPM tests upstream, to that end we need the swtpm
utility, which is only available in Jammy, not Focal. Update our
custom nodeset to use the new label.
Change-Id: Id24a69765d168c2d0c6fd696e697d6b25314854b
The functionality of skipdist changed with tox, now if skipdist is
enabled with usedevelop the project does not get installed. This would
result in whitebox not being properly installed in the environment and
subsequent tox tests failing. Removing skipdist to be inline with new
tox expectations.
Change-Id: I839bf50e0f36174575b78b5065b865995e191b78
Add vdpa smoke test for [1]. The network, subnet, port creation, and
verification had a lot of similarities to the test_sriov.SRIOVBase
class. Moved these common methods to the base.BaseWhiteboxComputeTest
class and updated impacted tests accordingly. In addition the sriov
tests were reliant on provider_net_base_segmentation_id for configuring
the vlan id for the network. To allow the vdpa and sriov networks their
own vlan, moved the vlan id configuration to whitebox_hardware via
sriov_vlan_id and vdpa_vlan_id.
[1] https://specs.openstack.org/openstack/nova-specs/specs/wallaby/implemented/libvirt-vdpa-support.html
Change-Id: Ia823d0503dbfb97eda35c6d3cf09a38407802fed
Add aditional tests based around [1] that introduces guest deployments
with multi-NUMA. The first new test is based on a symmetrical load with
the same number of vCPUs and memory per physical NUMA. The second test
limits a quarter of the resources to land on one NUMA and the remaining
75% on the other.
For example a 4 vCPU 1024 RAM guest would configured NUMA 0 to hold 1
vCPU and 256 with NUMA 1 would hold the remaining for the guest. This
type of deployment models high scale NFV architecture, where the control
plane vCPUs may all be shared on a specific NUMA while the dataplane
vCPUs would want to be dedicated and land on a NUMA that is connected to
the compute host's NICs.
[1] https://specs.openstack.org/openstack/nova-specs/specs/victoria/implemented/use-pcpu-vcpu-in-one-instance.html
Change-Id: Iab013b22e60d9d86666fedd76b5a73fe45b3bb98
For RHEL8 the secure boot attribute is not explicitly set to no when a
guest is deployed with just UEFI. Updated test to account for guests
that do not set secure boot to no explicitly.
Change-Id: I6c069a3385dccb3616585d938593146e0fa81387
Test deploying with multiple vGPU types. Assumes custom traits have
already been applied to the deployment. Based on the provided custom
trait/mdev_type mapping, the test will create a flavor using the trait,
create a guest from the flavor, and confirm the mdev_type of the
allocated vgpu device matches the expected mdev_type.
Change-Id: I120094dad4511b6876e4c19be9271e37920480cc
The commit [1] added a THT parameter that can set the maximum number of
disks that can be attached to a single guest. Refactored VirtioSCSIDisk
into ultimately three new classes.
* VirtioSCSIBase - parent class hold standard setup and supporting
methods for test cases
* VirtioSCSIDiskMultiAttachment - repuprose of the test methods from
VirtioSCSIDisk which are meant to test guest support of six or more
disks
* VirtioSCSIDiskRestrictAttachments - New test method that validates
[1] is being enforced correctly.
Since [1] could be set to a value less than six, added skip checks for
VirtioSCSIDiskMultiAttachment if the max allowed disks that can be
attached are six or less.
[1] https://review.opendev.org/c/openstack/puppet-nova/+/708666/
Change-Id: I78f7f47ffa2644c71945bba2b5c1af29e0603363
Add two UEFI boot tests one that boots a guest with just UEFI enabled
and a second test that boots a guest with UEFI and secure boot.
Change-Id: Iae8632cf2d8e765e9ae9f56ed98ad954c58484a3
Add an inventory check when testing vGPU to confirm inventory has
updated correctly after instance(s) with vGPU resources have been
deleted.
Change-Id: I9a016e7fc81e4b3324dcc25c5f59358b1b2b528a
Adds test support for attaching/detaching SR-IOV ports to guests. [1]
These tests pull from the original tempest format [2] from
AttachInterfacesTestJSON.test_reassign_port_between_servers. It adds
additional checks around the guest XML as well as checking within the
guest for the SR-IOV vendor/device id.
Commit also moves _get_pci_addr_from_device from vgpu to hardware.py to
allow it to be called from different tests beyond vgpu.
[1] https://bugs.launchpad.net/nova/+bug/1685152
[2] https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_attach_interfaces.py#L295
Change-Id: I340fd6486b0a179830e6e559281adc257fefb4bd
Update the NUMAAffinity SR-IOV tests to also include policy on a per
port level to test [1]. Tests validate results when ports have a common
policy, different policies, and evaluate precedence when the flavor has
a different value from the ports utilized.
In addition add tests around policy using image metadata as well. Also
include two config options that confirm if image level or port level
affinity configuration is supported.
[1] https://review.opendev.org/c/openstack/nova/+/773792/
Change-Id: Ic897ddb2f86c1de27342f56b3546735ed2829aec
The original assumption that the XML pci bus address will be the same
within the guest when checking the guest for the vGPU device is
incorrect. Depending on the guest firmware the guest can renumber the
address with an address that is different from the XML.
Update no longer uses the pci address found in the XML and instead does
a wildcard grep search in /sys/bus/pci/devices/*/vendor for the vGPU
vendor ID. It also greps that output to confirm there is a valid PCI
address in the path.
Change-Id: Iacdc1947f4c0800aa49fd6d6ec9fae5b2da010d8
The reboot_server helper method that was added to tempest [1] was part
of tempset tag 28.1.0. Downstream 16.2 limits git installation to
28.0.0 and no longer supports clone from master. Taking logic from [1]
for reboot_server and applying it to the base whitbox test class
since there are two tests that currently leverage the method.
[1] ea2b59ce61
Change-Id: If01f0bd4a12717067f59d3ec2421947b64b776e2
This is a continuation of [1], leaving RAM as 64MB for vGPU tests while
using cirros 0.5.0+ will result in a kernel panic. Updating flavor to
take the RAM size provided by tempest config.
[1] 159f57d395
Change-Id: I0432704a651bf8927354cabd0d8c3e42b8e8525f