OpenStack Block Storage (Cinder)
d028556263
This patch is to implement generic Quality-of-Service(QoS) support for volumes. The goal is to add an interface so that cloud/Cinder admins can use to set volume QoS, which can be enforced either in hypervisor or on Cinder back-end or both. QoS specifications are added as a standalone (only visible to admin) entity. So admin can create/update/delete and associate/disassociate QoS specifications to other entities, in this case volume types. Note that while it's possible for Cinder to set the granularity of QoS control to every single volume, this patch puts the control granularity to the level of volumes of the same type to minimize the impact of other Cinder parts. In other words, the design is to bond QoS with volume types. So Cinder admin can associate volume types with QoS specifications, and volumes of same volume type share the same QoS specifications. QoS can mean a lot different things that it's unlikely we can come up with a interpretation that all vendors can agree on. So the approach this implementation takes is to make Quality-of-Service specs as free-from, i.e. expressed as key/value pairs. Changes: - Add a quality_of_service_specs table, using adjacency list relation to store a specs entry and its detailed specs in key/values. Note that to be able to distinguish where should the QoS specs be consumed, each QoS specs entity will have a 'consumer' (i.e. fixed key) with the value of where admin would like the QoS policy to be enforced/consumed, currently these three values are considered valid: 'front-end' (Nova Compute), 'back-end' (Cinder back-end), 'both'. The default value for 'consumer' is 'back-end'; - Add a new API extension 'qos_specs_manage' to allow list/create/update/ delete/associate/disassociate of QoS specs; - Add volume/qos_specs internal API for qos specs manipulation; - Add 'qos_specs' info to data structure when initialize_connection() is called. - Add 'qos_specs' to request_specs and filter properties for a volume create request. TODO - Modify 'type_manage' API extension to be able to accept qos info. - Modify volume_types.create() to accept qos info and do the checks. DocImpact implement blueprint: pass-ratelimit-info-to-nova Change-Id: Iabc61b941aaff10395b30e2045e3421369a317e2 |
||
|---|---|---|
| bin | ||
| cinder | ||
| contrib | ||
| doc | ||
| etc/cinder | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .testr.conf | ||
| babel.cfg | ||
| CONTRIBUTING.md | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| openstack-common.conf | ||
| pylintrc | ||
| README.rst | ||
| requirements.txt | ||
| run_tests.sh | ||
| setup.cfg | ||
| setup.py | ||
| taskflow.conf | ||
| test-requirements.txt | ||
| tox.ini | ||
The Choose Your Own Adventure README for Cinder
You have come across a storage service for an open cloud computing service. It has identified itself as "Cinder." It was abstracted from the Nova project.
To monitor it from a distance: follow @openstack on twitter.
To tame it for use in your own cloud: read http://docs.openstack.org
To study its anatomy: read http://cinder.openstack.org
To dissect it in detail: visit http://github.com/openstack/cinder
To taunt it with its weaknesses: use http://bugs.launchpad.net/cinder
To watch it: http://jenkins.openstack.org
To hack at it: read HACKING.rst