For the Liberty release there is a proposal  to allow storage backends to
push capabilities of their pools . Eventually we would want some common
capabilities to graduate into becoming a
well defined capability. The
point of this spec is to agree on the initial
well defined capabilities.
well defined capabilities will allow the deployer to see what
common capabilities are shared beyond their deployed backends in Cinder.
well defined capabilities are:
Keep in mind this is just an agreement that these are common features that a backend could support. As shown in the proposal of how this will work , backends will still be able to push up the specific keys they look for in volume types for these capabilities.
Data model impact¶
None. This information comes directly from the volume drivers, reported to the scheduler, to the Cinder API.
REST API impact¶
Other end user impact¶
Other deployer impact¶
Volume driver maintainers will need report capabilities from their driver to the scheduler. They can get this information directly from the backend and pass it right up to the scheduler if it already follows the format specified earlier. If not, it’s up to the driver to parse the response from the backend in a format the scheduler will understand. If capabilities are not being reported, the default False on features will be done.
- Primary assignee:
Standardize on the Capabilities here. Right here, right now.
The developer docs for driver maintainers will need to be updated to include the list of common capabilities the maintainer needs to have their driver push that they support. By default capabilities are marked as False, as in not being supported by the driver.