Manila/QoS

=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=' True' or ' 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:

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.
 * 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



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   Associates qos specs with specified share type.

manila qos-create [--max_kbps ] [--min_kbps ] [--max_iops ] [--min_iops ] [ ...] 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 ]  Deletes a specified qos specs.

manila qos-disassociate   Disassociates qos specs from specified share type.

manila qos-disassociate-all  Disassociates qos specs from all associations.

manila qos-get-association  Gets all associations for specified qos specs.

manila qos-key  key=value [key=value ...] Sets or unsets specifications for a qos spec.

manila qos-list Lists qos specs.

manila qos-show  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.