Jump to: navigation, search

Manila/QoS

< Manila
Revision as of 13:12, 12 November 2015 by Zhongjun2 (talk | contribs) (Method 1)

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、eg: share_type: qos_support='<is> True' or '<is> False'

                               netapp:max_iops=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)

2、eg: share_type: qos_support='<is> True' or '<is> False'

                              qos:netapp:max_iops=100
           driver update: qos_support=true

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.

Sub Pages