]> review.fuel-infra Code Review - openstack-build/cinder-build.git/commit
Implement QoS support for volumes
authorZhiteng Huang <zhiteng.huang@intel.com>
Sat, 18 May 2013 14:21:28 +0000 (22:21 +0800)
committerZhiteng Huang <zhithuang@ebaysf.com>
Fri, 23 Aug 2013 02:21:46 +0000 (10:21 +0800)
commitd0285562632c329f45cc1cf65eae71f9532d3613
treea4e8cc346db07d09560788692aebcd3c210a7d2f
parent61db6db85ed3ad90682cfea5d1aa8c3866e355b5
Implement QoS support for volumes

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
17 files changed:
cinder/api/contrib/qos_specs_manage.py [new file with mode: 0644]
cinder/db/api.py
cinder/db/sqlalchemy/api.py
cinder/db/sqlalchemy/migrate_repo/versions/018_add_qos_specs.py [new file with mode: 0644]
cinder/db/sqlalchemy/models.py
cinder/exception.py
cinder/scheduler/filter_scheduler.py
cinder/tests/api/contrib/test_qos_specs_manage.py [new file with mode: 0644]
cinder/tests/db/test_qos_specs.py [new file with mode: 0644]
cinder/tests/policy.json
cinder/tests/test_migrations.py
cinder/tests/test_qos_specs.py [new file with mode: 0644]
cinder/tests/test_volume_types.py
cinder/volume/flows/create_volume.py
cinder/volume/manager.py
cinder/volume/qos_specs.py [new file with mode: 0644]
cinder/volume/volume_types.py