openstack
/
whitebox-tempest-plugin
Code Issues Proposed changes
Tempest plugin for whitebox testing. For testing things not exposed through the REST APIs.
335 Commits 1 Branch 2 Tags 23 MiB
Python 98.3%
Shell 1%
Jinja 0.7%
Go to file
James Parker 071426c223 Test resize with mem_page_size in flavor 
These tests are meant to address issue [1]. It adds three new testcases:

 * test_hugepage_resize_keyword_large_to_small
 * test_hugepage_resize_explicit_pagesize_to_small
 * test_hugepage_resize_explicit_size_to_size

All three tests follow the same basic procedure, spawn a guest with a
flavor using hw:mem_page_size:<size_a>, resize the guest to a flavor
with a different size hw:mem_page_size:<size_b>, and then resize the
guest back to the original flavor. Throughout the tests XML checks are
conducted to ensure the page size is accurate for the present flavor.

Instead of trying to dynamically determine the hugepage sizes configured
on the computes, a new config parameter was added to define what
hugepage sizes are available on the host. To avoid dynamic ram
calculation sizes for the guest based on available hugepages, a guest
ram parameter was also added so users may define the size to use when
spawning guests.

We also need a new job that has multiple hugepage sizes configured. We
cannot use our existing whitebox-devstack-multinode job because that
one runs tests that dynamically turn on file backed memory, which is
incompatible with hugepages. This commit adds tasks into job setup
that allows for the setup of hugepages.

In our devstack plugin.sh, we set track_instance_changes to True
(devstack defaults it to False) to make sure the scheduler has the
latest information about available huge pages, and avoid a race
whereing instances failed to schedule because our lone 1G page
still appeared used by an instance that had actually beed fully
deleted.

[1] https://bugs.launchpad.net/nova/+bug/1831269

Change-Id: I5282df3b20c24a909f3b7bb97214206bc07e5b91
 		2024-04-18 08:18:56 +02:00
devstack Test resize with mem_page_size in flavor 2024-04-18 08:18:56 +02:00
playbooks Test resize with mem_page_size in flavor 2024-04-18 08:18:56 +02:00
whitebox_tempest_plugin Test resize with mem_page_size in flavor 2024-04-18 08:18:56 +02:00
.gitignore Update gitignore 2019-04-02 15:51:24 +00:00
.gitreview Fix repo after rename 2020-06-13 07:08:00 +02:00
.stestr.conf Subclass API tests instead of scenario 2018-07-13 10:38:09 -04:00
.zuul.yaml Test resize with mem_page_size in flavor 2024-04-18 08:18:56 +02:00
LICENSE Includes license and fixes copyright headers 2017-12-12 17:55:00 +01:00
README.rst Fix typo 2022-05-12 16:29:27 +02:00
requirements.txt "Fix" double declaration of barbican-templest-plugin 2023-12-22 12:54:42 -05:00
setup.cfg Update jobs for Bobcat development cycle 2023-05-26 12:24:28 -04:00
setup.py Initial commit 2017-12-12 17:55:00 +01:00
test-requirements.txt Remove tempest and oslo.log from requirements.txt 2020-07-30 12:09:17 -04:00
tox.ini Add global nodes variable 2023-11-13 13:39:53 -05:00

README.rst

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.

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

  1. Tempest needs to be installed and configured.

  2. 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-plugin

  3. Configure Tempest.

    The exact configuration will depend on the deployment. There is no configuration reference yet, have a look at whitebox_tempest_plugin/config.py instead. 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

  4. 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.