Sean McGinnis e7b40242f8 Add driver interface checks

This is the start of an effort to both validate that drivers fully
implement the expected minimum requirements as well as to create a clear
place for driver developers to learn what needs to be implemented and get
documentation explaining what is expected for each method.

This also enables us to create tooling for documenting the available
drivers and their capabilities, to some degree. A follow up patch will
show some of what I'm thinking there, but it will make it possible to write
scripts for different needs.

This is somewhat a cleanup attempt to the ABC work that was started a
while back. This does not aim to replace that effort, but give a
mechanism for some of the things expected out of that effort that ended
up not being possible with how it evolved.

In most cases we do not really care if a driver is inherited from a
certain base class, just that it conforms to the given interface.

The interface/inheritance work really centers around two separate
things:

 * Ensuring drivers conform to an expected interface
 * Allowing code reuse and common implementation

This is really for the first item. Additional work is needed to complete
the ABC work we've done, but that really focuses on the second item, and
is out of scope for the intent of this patch.

Change-Id: I4168225126fe88c31712d94f0a130e9e7ede3446

2016-06-13 15:21:47 +00:00

2.6 KiB

Raw Blame History

Drivers

Cinder exposes an API to users to interact with different storage backend solutions. The following are standards across all drivers for Cinder services to properly interact with a driver.

Minimum Features

Minimum features are enforced to avoid having a grid of what features are supported by which drivers and which releases. Cinder Core requires that all drivers implement the following minimum features.

Core Functionality

Volume Create/Delete
Volume Attach/Detach
Snapshot Create/Delete
Create Volume from Snapshot
Get Volume Stats
Copy Image to Volume
Copy Volume to Image
Clone Volume
Extend Volume

Volume Stats

Volume stats are used by the different schedulers for the drivers to provide a report on their current state of the backend. The following should be provided by a driver.

driver_version
free_capacity_gb
reserved_percentage
storage_protocol
total_capacity_gb
vendor_name
volume_backend_name

NOTE: If the driver is unable to provide a value for free_capacity_gb or total_capacity_gb, keywords can be provided instead. Please use 'unknown' if the array cannot report the value or 'infinite' if the array has no upper limit.

Feature Enforcement

All concrete driver implementations should use the cinder.interface.volumedriver decorator on the driver class:

@interface.volumedriver
class LVMVolumeDriver(driver.VolumeDriver):

This will register the driver and allow automated compliance tests to run against and verify the compliance of the driver against the required interface to support the Core Functionality listed above.

Running tox -e compliance will verify all registered drivers comply to this interface. This can be used during development to perform self checks along the way. Any missing method calls will be identified by the compliance tests.

The details for the required volume driver interfaces can be found in the cinder/interface/volume_*_driver.py source.

2.6 KiB Raw Blame History