8fc6fa5414
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
Whitebox Tempest plugin
This is a Tempest plugin for whitebox testing. While Tempest's scope is limited to only the REST APIs, whitebox allows tests to peak behind the curtain, similar to how a cloud admin might. Examining things on the compute host(s) and/or the controller(s) is not only allowed, it's required for a test to be in whitebox's scope. Whitebox tests must still be REST API-driven, however their assertions can involve things like the instance XML (if the Nova libvirt driver is in use) or the database.
- Bugs: https://storyboard.openstack.org/#!/project/1162
- IRC: #openstack-qa on OFTC
Requirements
While Tempest is cloud-agnostic because all clouds expose the same OpenStack APIs (with some caveats around extensions), whitebox peaks behind the curtain, and thus is coupled to the way the cloud was deployed. Currently, devstack and TripleO (with undercloud and overcloud) are supported, with only devstack being tested in CI.
Some tests have specific hardware requirements. These should be documented as config options, and tests are expected to skip if their hardware requirements are not declared in the configuration.
Install, configure and run
Tempest needs to be installed and configured.
Install the plugin.
This should be done from source. :
WORKSPACE=/some/directory cd $WORKSPACE git clone https://opendev.org/openstack/whitebox-tempest-plugin sudo pip install whitebox-tempest-pluginConfigure Tempest.
The exact configuration will depend on the deployment. There is no configuration reference yet, have a look at
whitebox_tempest_plugin/config.pyinstead. As an example, here is a configuration for a multinode TripleO deployment:[whitebox]ctlplane_addresses = compute-0.localdomain:192.168.24.6,compute-1.localdomain:192.168.24.12 ctlplane_ssh_username = heat-admin ctlplane_ssh_private_key_path = /home/stack/.ssh/id_rsa containers = true max_compute_nodes = 2 # Some tests depend on there being a single # (available) compute node
Execute the tests. :
tempest run --serial --regex whitebox_tempest_plugin.Important
Whitebox expects its tests to run one at a time. Make sure to pass --serial or --concurrency 1 to tempest run.
How to add a new test
Tests should fit whitebox's scope. If a test intereacts with REST
APIs and nothing else, it is better suited for Tempest itself. New tests
should be added in their respective subdirectories. For example, tests
that use the compute API live in
whitebox_tempest_plugin/api/compute. Test code does not
need unit tests, but helpers or utilities do. Unit tests live in
whitebox_tempest_plugin/tests. Whitebox does not adhere to
the Tempest plugin interface
<https://docs.openstack.org/tempest/latest/plugin.html>. As
mentioned, whitebox tests run one at a time, so it's safe for a test to
modify the environment and/or be destructive, as long as it cleans up
after itself. For example, changing Nova configuration values and/or
restarting services is acceptable, as long as the original values and
service state are restored.