071426c223
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 |
||
|---|---|---|
| .. | ||
| templates | ||
| whitebox | ||