cinder/doc/source/devref/drivers.rst
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

85 lines
2.6 KiB
ReStructuredText

..
Copyright (c) 2013 OpenStack Foundation
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
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.