6ca6f6fce6
When an admin creates a snapshot of another project owners instance, either via the createImage API directly, or via the shelve or createBackup APIs, the admin project is the owner of the image and the owner of the instance (in another project) cannot "see" the image. This is a problem, for example, if an admin shelves a tenant user's server and then the user tries to unshelve the server because the user will not have access to get the shelved snapshot image. This change fixes the problem by leveraging the sharing feature [1] in the v2 image API. When a snapshot is created where the request context project_id does not match the owner of the instance project_id, the instance owner project_id is granted sharing access to the image. By default, this means the instance owner (tenant user) can get the image directly via the image ID if they know it, but otherwise the image is not listed for the user to avoid spamming their image listing. In the case of unshelve, the end user does not need to know the image ID since it is stored in the instance system_metadata. Regardless, the user could accept the pending image membership if they want to see the snapshot show up when listing available images. Note that while the non-admin project has access to the snapshot image, they cannot delete it. For example, if the user tries to delete or unshelve a shelved offloaded server, nova will try to delete the snapshot image which will fail and log a warning since the user does not own the image (the admin does). However, the delete/unshelve operations will not fail because the image cannot be deleted, which is an acceptable trade-off. Due to some very old legacy virt driver code which started in the libvirt driver and was copied to several other drivers, several virt drivers had to be modified to not overwrite the "visibility=shared" image property by passing "is_public=False" when uploading the image data. There was no point in the virt drivers setting is_public=False since the API already controls that. It does mean, however, that the bug fix is not really in effect until both the API and compute service code has this fix. A functional test is added which depends on tracking the owner/member values in the _FakeImageService fixture. Impacted unit tests are updated accordingly. [1] https://developer.openstack.org/api-ref/image/v2/index.html#sharing Conflicts: nova/compute/api.py nova/compute/utils.py NOTE(seyeongkim): The conflict is due to not having change |
||
---|---|---|
.. | ||
api | ||
api_samples_test_base | ||
cells | ||
cmd | ||
compute | ||
conductor | ||
conf | ||
console | ||
consoleauth | ||
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_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.