1c6b2fce28
The recent "Meltdown" CVE fixes have resulted in a critical performance penalty[*] that will impact every Nova guest with certain CPU models. I.e. assume you have applied all the "Meltdown" CVE fixes, and performed a cold reboot (explicit stop & start) of all Nova guests, for the updates to take effect. Now, if any guests that are booted with certain named virtual CPU models (e.g. "IvyBridge", "Westmere", etc), then those guests, will incur noticeable performance degradation[*], while being protected from the CVE itself. To alleviate this guest performance impact, it is now important to specify an obscure Intel CPU feature flag, 'PCID' (Process-Context ID) -- for the virtual CPU models that don't already include it (more on this below). To that end, this change will allow Nova to explicitly specify CPU feature flags via a new configuration attribute, `cpu_model_extra_flags`, e.g. in `nova.conf`: ... [libvirt] cpu_mode = custom cpu_model = IvyBridge cpu_model_extra_flags = pcid ... NB: In the first iteration, the choices for `cpu_model_extra_flags` is restricted to only 'pcid' (the option is case-insensitive) -- to address the earlier mentioned guest performance degradation. A future patch will remove this restriction, allowing to add / remove multiple CPU feature flags, thus making way for other useful features. Some have asked: "Why not simply hardcode the 'PCID' CPU feature flag into Nova?" That's not graceful, and more importantly, impractical: (1) Not every Intel CPU model has 'PCID': - The only Intel CPU models that include the 'PCID' capability are: "Haswell", "Broadwell", and "Skylake" variants. - The libvirt / QEMU Intel CPU models: "Nehalem", "Westmere", "SandyBridge", and "IvyBridge" will *not* expose the 'PCID' capability, even if the host CPUs by the same name include it. I.e. 'PCID' needs to be explicitly when using the said virtual CPU models. (2) Magically adding new CPU feature flags under the user's feet impacts live migration. [*] https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU Conflicts: nova/virt/libvirt/driver.py NOTE(lyarwood): The above is a trivial warning log translation conflict required prior to stable/pike. Closes-Bug: #1750829 Change-Id: I6bb956808aa3df58747c865c92e5b276e61aff44 (cherry picked from commit |
||
---|---|---|
.. | ||
api | ||
api_samples_test_base | ||
cells | ||
cert | ||
cmd | ||
compute | ||
conductor | ||
console | ||
consoleauth | ||
db | ||
fake_loadables | ||
image | ||
keymgr | ||
monkey_patch_example | ||
network | ||
notifications | ||
objects | ||
pci | ||
scheduler | ||
servicegroup | ||
ssl_cert | ||
virt | ||
volume | ||
README.rst | ||
__init__.py | ||
cast_as_call.py | ||
conf_fixture.py | ||
fake_block_device.py | ||
fake_build_request.py | ||
fake_console_auth_token.py | ||
fake_crypto.py | ||
fake_flavor.py | ||
fake_hosts.py | ||
fake_instance.py | ||
fake_ldap.py | ||
fake_network.py | ||
fake_network_cache_model.py | ||
fake_notifier.py | ||
fake_pci_device_pools.py | ||
fake_policy.py | ||
fake_processutils.py | ||
fake_request_spec.py | ||
fake_server_actions.py | ||
fake_volume.py | ||
fake_xvp_console_proxy.py | ||
image_fixtures.py | ||
matchers.py | ||
policy_fixture.py | ||
test_api_validation.py | ||
test_availability_zones.py | ||
test_baserpc.py | ||
test_block_device.py | ||
test_cache.py | ||
test_cinder.py | ||
test_conf.py | ||
test_configdrive2.py | ||
test_context.py | ||
test_crypto.py | ||
test_exception.py | ||
test_fixtures.py | ||
test_flavors.py | ||
test_hacking.py | ||
test_hash_ring.py | ||
test_hooks.py | ||
test_instance_types_extra_specs.py | ||
test_iptables_network.py | ||
test_ipv6.py | ||
test_loadables.py | ||
test_matchers.py | ||
test_metadata.py | ||
test_notifications.py | ||
test_notifier.py | ||
test_nova_manage.py | ||
test_pipelib.py | ||
test_policy.py | ||
test_profiler.py | ||
test_quota.py | ||
test_rpc.py | ||
test_safeutils.py | ||
test_service.py | ||
test_service_auth.py | ||
test_signature_utils.py | ||
test_test.py | ||
test_test_utils.py | ||
test_utils.py | ||
test_uuid_sentinels.py | ||
test_versions.py | ||
test_weights.py | ||
test_wsgi.py | ||
utils.py |
README.rst
OpenStack Nova Testing Infrastructure
This README file attempts to provide current and prospective contributors with everything they need to know in order to start creating unit tests for nova.
Note: the content for the rest of this file will be added as the work items in the following blueprint are completed: https://blueprints.launchpad.net/nova/+spec/consolidate-testing-infrastructure
Test Types: Unit vs. Functional vs. Integration
TBD
Writing Unit Tests
TBD
Using Fakes
TBD
test.TestCase
The TestCase class from nova.test (generally imported as test) will automatically manage self.stubs using the stubout module and self.mox using the mox module during the setUp step. They will automatically verify and clean up during the tearDown step.
If using test.TestCase, calling the super class setUp is required and calling the super class tearDown is required to be last if tearDown is overridden.
Writing Functional Tests
TBD
Writing Integration Tests
TBD
Tests and Exceptions
A properly written test asserts that particular behavior occurs. This can be a success condition or a failure condition, including an exception. When asserting that a particular exception is raised, the most specific exception possible should be used.
In particular, testing for Exception being raised is almost always a mistake since it will match (almost) every exception, even those unrelated to the exception intended to be tested.
This applies to catching exceptions manually with a try/except block, or using assertRaises().
Example:
self.assertRaises(exception.InstanceNotFound, db.instance_get_by_uuid,
elevated, instance_uuid)
If a stubbed function/method needs a generic exception for testing purposes, test.TestingException is available.
Example:
def stubbed_method(self):
raise test.TestingException()
self.stubs.Set(cls, 'inner_method', stubbed_method)
obj = cls()
self.assertRaises(test.TestingException, obj.outer_method)
Stubbing and Mocking
Whenever possible, tests SHOULD NOT stub and mock out the same function.
If it's unavoidable, tests SHOULD define stubs before mocks since the TestCase cleanup routine will un-mock before un-stubbing. Doing otherwise results in a test that leaks stubbed functions, causing hard-to-debug interference between tests1.
If a mock must take place before a stub, any stubs after the mock call MUST be manually unset using self.cleanUp calls within the test.