a721ca5f51
The VIR_MIGRATE_PARAM_PERSIST_XML parameter was introduced in libvirt v1.3.4 and is used to provide the new persistent configuration for the destination during a live migration: https://libvirt.org/html/libvirt-libvirt-domain.html#VIR_MIGRATE_PARAM_PERSIST_XML Without this parameter the persistent configuration on the destination will be the same as the original persistent configuration on the source when the VIR_MIGRATE_PERSIST_DEST flag is provided. As Nova does not currently provide the VIR_MIGRATE_PARAM_PERSIST_XML param but does provide the VIR_MIGRATE_PERSIST_DEST flag this means that a soft reboot by Nova of the instance after a live migration can revert the domain back to the original persistent configuration from the source. Note that this is only possible in Nova as a soft reboot actually results in the virDomainShutdown and virDomainLaunch libvirt APIs being called that recreate the domain using the persistent configuration. virDomainReboot does not result in this but is not called at this time. The impact of this on the instance after the soft reboot is pretty severe, host devices referenced in the original persistent configuration on the source may not exist or could even be used by other users on the destination. CPU and NUMA affinity could also differ drastically between the two hosts resulting in the instance being unable to start etc. As MIN_LIBVIRT_VERSION is now > v1.3.4 this change simply includes the VIR_MIGRATE_PARAM_PERSIST_XML param using the same updated XML for the destination as is already provided to VIR_MIGRATE_PARAM_DEST_XML. Conflicts: nova/tests/unit/virt/libvirt/test_driver.py nova/tests/unit/virt/test_virt_drivers.py nova/virt/libvirt/driver.py nova/virt/libvirt/guest.py NOTE(lyarwood): Conflicts as If0a091a7441f2c3269148e40ececc3696d69684c (libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION for "Rocky"), Id9ee1feeadf612fa79c3d280cee3a614a74a00a7 (libvirt: Remove usage of migrateToURI{2} APIs) and I3af68f745ffb23ef2b5407ccec0bebf4b2645734 (Remove mox in test_virt_drivers.py) are not present on stable/queens. As a result we can now add the parameter directly in _live_migration_operation before calling down into guest.migrate. Co-authored-by: Tadayoshi Hosoya <tad-hosoya@wr.jp.nec.com> Closes-Bug: #1890501 Change-Id: Ia3f1d8e83cbc574ce5cb440032e12bbcb1e10e98 (cherry picked from commit |
||
---|---|---|
.. | ||
api | ||
api_samples_test_base | ||
cells | ||
cmd | ||
compute | ||
conductor | ||
console | ||
consoleauth | ||
db | ||
fake_loadables | ||
image | ||
keymgr | ||
monkey_patch_example | ||
network | ||
notifications | ||
objects | ||
pci | ||
privsep | ||
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_diagnostics.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_hooks.py | ||
test_identity.py | ||
test_instance_types_extra_specs.py | ||
test_iptables_network.py | ||
test_ipv6.py | ||
test_json_ref.py | ||
test_loadables.py | ||
test_matchers.py | ||
test_metadata.py | ||
test_notifications.py | ||
test_notifier.py | ||
test_nova_manage.py | ||
test_policy.py | ||
test_profiler.py | ||
test_quota.py | ||
test_rpc.py | ||
test_safeutils.py | ||
test_service.py | ||
test_service_auth.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.