1ff029c1c3
The BuildRequest represents a server in the API until the scheduler picks a host in a cell and we create the instance record in that cell and update the instance mapping to point at the cell. If the user deletes the BuildRequest before the instance record is created in a cell, the conductor schedule_and_build_instances method cleans up the resource allocations created by scheduler and then continues to the next instance (if it's a multi-create request). The point is the instance does not get created in a cell, the BuildRequest is gone, and the instance mapping is left pointing at no cell - effectively orphaned. Furthermore, the archive_deleted_rows command change I483701a55576c245d091ff086b32081b392f746e to cleanup instance mappings for archived instances will not catch and cleanup the orphan instance mapping because there never was an instance record to delete and archive (the BuildRequest was deleted before the instance record was created, and the BuildRequest is hard deleted so there is no archive). This change simply deletes the InstanceMapping record in case the BuildRequest is already gone by the time we finish scheduling and we do not create the instance record in any cell. Change-Id: Ia03577ae41f010b449e47ff5b69b432d74f8467b Related-Bug: #1784074 Related-Bug: #1773945 |
||
---|---|---|
.. | ||
api | ||
cmd | ||
compute | ||
conductor | ||
conf | ||
console | ||
db | ||
fake_loadables | ||
image | ||
keymgr | ||
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_requests.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_fake_notifier.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_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.