Difference between revisions of "Manila/QoS"
(→=) |
(→Method 1) |
||
(36 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | + | =Intro= | |
Line 6: | Line 6: | ||
The goal is to add an interface so that Manila admins can use to set share QoS | The goal is to add an interface so that Manila admins can use to set share QoS | ||
specification (IOPS, bandwidth, Latency, priority and other vendor specified attributes), | specification (IOPS, bandwidth, Latency, priority and other vendor specified attributes), | ||
− | which can be enforced in | + | which can be enforced in Manila back-end; |
− | Problem description | + | The design for QoS isn't complete. We have a vision for the feature, and we're trying to define the details. |
+ | |||
+ | =Problem description= | ||
The current implementation of QoS spec management process in | The current implementation of QoS spec management process in | ||
Line 19: | Line 21: | ||
usability and user experience of this task. | usability and user experience of this task. | ||
− | + | =Method 1= | |
+ | Use the extra-specs tables with vendor scoped keys. | ||
+ | |||
+ | How to make sure the user need create a share with qos? | ||
+ | |||
+ | 1、Add qos_support in share type to make sure the user need create a share with qos. | ||
+ | |||
+ | common qos: | ||
+ | qos:max_iops | ||
+ | qos:min_iops | ||
+ | qos:max_bandwith | ||
+ | qos:min_bandwith | ||
+ | |||
+ | max: The prefix 'Max_' is means the max value can not be exceed. | ||
+ | |||
+ | min: The prefix 'min_' is means the min value is a soft limit, that make the current value is larger than the minimum value as much as possible. | ||
+ | |||
+ | eg: share_type: qos_support='<is> True' or '<is> False' | ||
+ | qos:max_iops=100 | ||
+ | netapp:max_test=100 | ||
+ | driver update: qos_support=true | ||
− | = | + | Add qos_support in common capabilities.(https://github.com/openstack/manila/blob/master/doc/source/devref/capabilities_and_extra_specs.rst) |
+ | |||
+ | =Method 2= | ||
Add an interface so that admins can use to express QoS requirements for shares | Add an interface so that admins can use to express QoS requirements for shares | ||
(of specific back-ends), which will be consumed by back-end drivers. | (of specific back-ends), which will be consumed by back-end drivers. | ||
− | - Add a new resource extension to 'types_extra_specs' API extension to allow list/create/update/delete | + | - Add a new resource extension to 'types_extra_specs' API extension to allow list/create/update/delete of type QoS specs. |
− | |||
- Modify 'type_manage' API extension to be able to accept QoS specification info. | - Modify 'type_manage' API extension to be able to accept QoS specification info. | ||
qos-associate Associates qos specs with specified share type. | qos-associate Associates qos specs with specified share type. | ||
Line 47: | Line 70: | ||
Create share from snapshot: If QoS is enabled and IOThrottling is available as the QoS key, set the | Create share from snapshot: If QoS is enabled and IOThrottling is available as the QoS key, set the | ||
qos spec of the share into the specified qos spec value. | qos spec of the share into the specified qos spec value. | ||
− | |||
− | |||
− | |||
− | |||
Database schema changes: | Database schema changes: | ||
Line 92: | Line 111: | ||
− | REST API impact | + | REST API impact: |
− | |||
* Extend share type creation response to include qos_specs_id field | * Extend share type creation response to include qos_specs_id field | ||
Line 102: | Line 120: | ||
* Add policy for the new extension | * Add policy for the new extension | ||
− | + | Other end user impact: | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Other end user impact | ||
− | |||
* Manila-ui should be updated to support this new extension. | * Manila-ui should be updated to support this new extension. | ||
Line 131: | Line 130: | ||
Associates qos specs with specified share type. | Associates qos specs with specified share type. | ||
− | manila qos-create <name> <key=value> [<key=value> ...] | + | manila qos-create <name> [--max_kbps <max_kbps>] [--min_kbps <min_kbps>] [--max_iops <max_iops>] [--min_iops <min_iops>] <key=value> [<key=value> ...] |
Creates a qos specs. | Creates a qos specs. | ||
+ | max: The prefix 'Max_' is means the max value can not be exceed. | ||
+ | |||
+ | min: The prefix 'min_' is means the min value is a soft limit, that make the current value is larger than the minimum value as much as possible. | ||
manila qos-delete [--force <True|False>] <qos_specs> | manila qos-delete [--force <True|False>] <qos_specs> | ||
Line 155: | Line 157: | ||
Shows a specified qos specs. | Shows a specified qos specs. | ||
− | + | =Question= | |
− | - | + | 1.Why QoS can not be used in the same way - extra specs with possibilities? |
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | Because the QoS is an independant resource and special feature. The QoS need a complete set of API. | |
− | |||
− | |||
+ | 2.Why associate QoS only with share type? why not tenant? user? specific share? | ||
+ | For user only need to see share_type. If user want to use QoS, then they will associate QoS with share type. | ||
+ | If we provide more access(such as: add QoS as a parameter when we creating a share), User will feel more | ||
+ | complicated. | ||
− | + | =Cinder QoS vs Manila QoS= | |
− | + | *Manila QoS add a few common capabilities in qos-create command. | |
+ | *Cinder support both front-end QoS and back-end QoS, Manila only support back-end QoS. | ||
− | Assignee(s) | + | =Assignee(s)= |
----------- | ----------- | ||
Line 182: | Line 182: | ||
zhaohua (zhaohua.zhao@huawei.com) | zhaohua (zhaohua.zhao@huawei.com) | ||
− | Work Items | + | =Work Items= |
− | |||
* Add logic to coordinate calling each driver's ``validate`` function | * Add logic to coordinate calling each driver's ``validate`` function | ||
Line 189: | Line 188: | ||
* Add ``validate`` function to lvm driver | * Add ``validate`` function to lvm driver | ||
− | Dependencies | + | =Dependencies= |
− | |||
− | + | Unit tests for all changed files | |
− | + | =Documentation Impact= | |
− | == | ||
− | |||
− | |||
− | + | * The manila API documentation will need to be updated to reflect the fact that the API may return a failure. | |
− | |||
− | + | ==Sub Pages== | |
− | |||
− | |||
− | |||
− | + | {{Special:PrefixIndex/:Manila/QoS|hideredirects=1}} |
Latest revision as of 11:26, 16 November 2015
Contents
Intro
https://blueprints.launchpad.net/manila/+spec/manila-support-qos
The goal is to add an interface so that Manila admins can use to set share QoS specification (IOPS, bandwidth, Latency, priority and other vendor specified attributes), which can be enforced in Manila back-end;
The design for QoS isn't complete. We have a vision for the feature, and we're trying to define the details.
Problem description
The current implementation of QoS spec management process in Manila provides no validation of the specs key/value pair. Administrators have no way to get a response as to whether the QoS spec key/value pair they just created is valid or not. The validation of the key/value pair only happens during the share creation process which is far too late by that point. Having a validation of the key/value pair done immediately within the QoS spec creation or edit process will significantly improve the usability and user experience of this task.
Method 1
Use the extra-specs tables with vendor scoped keys.
How to make sure the user need create a share with qos?
1、Add qos_support in share type to make sure the user need create a share with qos.
common qos:
qos:max_iops qos:min_iops qos:max_bandwith qos:min_bandwith
max: The prefix 'Max_' is means the max value can not be exceed.
min: The prefix 'min_' is means the min value is a soft limit, that make the current value is larger than the minimum value as much as possible.
eg: share_type: qos_support='<is> True' or '<is> False'
qos:max_iops=100 netapp:max_test=100 driver update: qos_support=true
Add qos_support in common capabilities.(https://github.com/openstack/manila/blob/master/doc/source/devref/capabilities_and_extra_specs.rst)
Method 2
Add an interface so that admins can use to express QoS requirements for shares (of specific back-ends), which will be consumed by back-end drivers.
- Add a new resource extension to 'types_extra_specs' API extension to allow list/create/update/delete of type QoS specs. - Modify 'type_manage' API extension to be able to accept QoS specification info.
qos-associate Associates qos specs with specified share type. qos-create Creates a qos specs. qos-delete Deletes a specified qos specs. qos-disassociate Disassociates qos specs from specified share type. qos-disassociate-all Disassociates qos specs from all associations. qos-get-association Gets all associations for specified qos specs. qos-key Sets or unsets specifications for a qos spec. qos-list Lists qos specs. qos-show Shows a specified qos specs.
- Modify share_types.create() to accept QoS specification info and do the checks. - Add 'qos_specs' to request_specs and filter properties for a share create request and pass to driver. - To enable the QoS for Manila driver, an qos spec needs to bind to a share type. All the following
changes apply to the Manila driver code. Create share: If QoS is enabled and specs is available as the QoS key, set the qos spec of the share into the specified qos spec value. Create snapshot: The QoS attributes will be copied to the snapshot. Create share from snapshot: If QoS is enabled and IOThrottling is available as the QoS key, set the qos spec of the share into the specified qos spec value.
Database schema changes:
- A new qos_specs_id boolean column will be added to the share_types table.
- A new quality_of_service_specs table will be created for a particular share types. There will be
one entry in quality_of_service_specs table for every share_type_id and specs_id combination. It will be a one-to-one relationship.
mysql> DESC quality_of_service_specs; +------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------+--------------+------+-----+---------+-------+ | created_at | datetime | YES | | NULL | | | updated_at | datetime | YES | | NULL | | | deleted_at | datetime | YES | | NULL | | | deleted | tinyint(1) | YES | | NULL | | | id | varchar(36) | NO | PRI | NULL | | | specs_id | varchar(36) | YES | MUL | NULL | | | key | varchar(255) | YES | | NULL | | | value | varchar(255) | YES | | NULL | | +------------+--------------+------+-----+---------+-------+ 8 rows in set (0.00 sec)
mysql> DESC share_types; +--------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------------+--------------+------+-----+---------+-------+ | created_at | datetime | YES | | NULL | | | updated_at | datetime | YES | | NULL | | | deleted_at | datetime | YES | | NULL | | | deleted | tinyint(1) | YES | | NULL | | | id | varchar(36) | NO | PRI | NULL | | | name | varchar(255) | YES | | NULL | | | qos_specs_id | varchar(36) | YES | MUL | NULL | | | is_public | tinyint(1) | YES | | NULL | | +--------------+--------------+------+-----+---------+-------+ 8 rows in set (0.00 sec)
REST API impact:
- Extend share type creation response to include qos_specs_id field
- Extend share type list to include qos_specs_id field
- Extend share type detail to include qos_specs_id field
- Add ability to create/delete a qos specs
- Add ability to associates/disassociate qos specs with specified share type
- Add policy for the new extension
Other end user impact:
- Manila-ui should be updated to support this new extension.
- python-manilaclient should be updated to allow the use of this new extension.
Proposed python-manilaclient shell interface::
manila qos-associate <qos_specs> <share_type_id> Associates qos specs with specified share type.
manila qos-create <name> [--max_kbps <max_kbps>] [--min_kbps <min_kbps>] [--max_iops <max_iops>] [--min_iops <min_iops>] <key=value> [<key=value> ...] Creates a qos specs.
max: The prefix 'Max_' is means the max value can not be exceed.
min: The prefix 'min_' is means the min value is a soft limit, that make the current value is larger than the minimum value as much as possible.
manila qos-delete [--force <True|False>] <qos_specs> Deletes a specified qos specs.
manila qos-disassociate <qos_specs> <share_type_id> Disassociates qos specs from specified share type.
manila qos-disassociate-all <qos_specs> Disassociates qos specs from all associations.
manila qos-get-association <qos_specs> Gets all associations for specified qos specs.
manila qos-key <qos_specs> <action> key=value [key=value ...] Sets or unsets specifications for a qos spec.
manila qos-list Lists qos specs.
manila qos-show <qos_specs> Shows a specified qos specs.
Question
1.Why QoS can not be used in the same way - extra specs with possibilities?
Because the QoS is an independant resource and special feature. The QoS need a complete set of API.
2.Why associate QoS only with share type? why not tenant? user? specific share?
For user only need to see share_type. If user want to use QoS, then they will associate QoS with share type. If we provide more access(such as: add QoS as a parameter when we creating a share), User will feel more complicated.
Cinder QoS vs Manila QoS
- Manila QoS add a few common capabilities in qos-create command.
- Cinder support both front-end QoS and back-end QoS, Manila only support back-end QoS.
Assignee(s)
Primary assignee:
zhongjun (jun.zhongjun@huawei.com)
Other contributors:
zhaohua (zhaohua.zhao@huawei.com)
Work Items
- Add logic to coordinate calling each driver's ``validate`` function
- Add ``validate`` function to base manila driver
- Add ``validate`` function to lvm driver
Dependencies
Unit tests for all changed files
Documentation Impact
- The manila API documentation will need to be updated to reflect the fact that the API may return a failure.