Jump to: navigation, search

Difference between revisions of "Manila/QoS"

(=)
Line 1: Line 1:
Manila support QoS Spec
+
=Manila support QoS Spec=
  
  
Line 8: Line 8:
 
which can be enforced in hypervisor or on Manila back-end or both;
 
which can be enforced in hypervisor or on Manila back-end or both;
  
Problem description
+
=Problem description=
  
 
The current implementation of QoS spec management process in
 
The current implementation of QoS spec management process in
Line 18: Line 18:
 
within the QoS spec creation or edit process will significantly improve the
 
within the QoS spec creation or edit process will significantly improve the
 
usability and user experience of this task.
 
usability and user experience of this task.
 
Proposed change
 
  
 
=Proposed change=
 
=Proposed change=
Line 49: Line 47:
  
  
Data model impact
+
=Data model impact=
-----------------
 
  
 
Database schema changes:
 
Database schema changes:
Line 92: Line 89:
  
  
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 98:
 
* Add policy for the new extension
 
* Add policy for the new extension
  
Validation Details
 
------------------
 
  
 
+
=Other end user impact=
Alternatives
 
------------
 
 
 
 
 
Security impact
 
---------------
 
 
 
This change introduces the concept about quality of service specs.
 
 
 
Notifications impact
 
--------------------
 
 
 
None
 
 
 
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 154: Line 132:
 
  manila qos-show <qos_specs>
 
  manila qos-show <qos_specs>
 
   Shows a specified qos specs.
 
   Shows a specified qos specs.
 
Performance Impact
 
------------------
 
 
None
 
 
Other deployer impact
 
---------------------
 
 
None
 
 
Developer impact
 
----------------
 
 
  
  
Line 181: Line 145:
 
   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 188: Line 151:
 
* Add ``validate`` function to lvm driver
 
* Add ``validate`` function to lvm driver
  
Dependencies
+
=Dependencies=
 
 
=======
 
  
 
Unit tests for all changed files
 
Unit tests for all changed files
  
Documentation Impact
+
=Documentation Impact=
====================
 
  
 
* The manila API documentation will need to be updated to reflect the fact that
 
* The manila API documentation will need to be updated to reflect the fact that
 
   the API may return a failure.
 
   the API may return a failure.
 
References
 
==========
 
 
None
 

Revision as of 09:26, 19 September 2015

Manila support QoS Spec

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 hypervisor or on Manila back-end or both;

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.

Proposed change

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.


Data model impact

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> <key=value> [<key=value> ...]
  Creates a qos specs.
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.


Implementation

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.