Open Stack

Hi, I'd like you to take a look at this patch for potential
DocImpact.
https://review.openstack.org/29737

Log:
commit 1f64306a770ccf105c2150b89a5784aee2acca04
Author: Zhiteng Huang <zhiteng.huang at intel.com>
Date:   Sat May 18 22:21:28 2013 +0800

    Implement QoS support for volumes
    
    This patch is to implement generic Quality-of-Service(QoS) support for volumes.
    The goal is 1) to add an interface so that cloud/Cinder admins can use to set
    volume rate-limit, which can be enforced either in hypervisor or on Cinder
    back-end or both; 2) to add an interface so that admins can use to express
    QoS requirements for volumes (of specific back-ends), which will be consumed
    by back-end drivers.
    
    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 create various volume types with different QoS requirements, 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
    intepreation that all vendors can agree on.  On the other hand, the
    throttling/rate-limiting is a notion that has clear defintion that everyone
    agrees on. So the approach this implementation takes is to break Quality-of-
    Service into two parts: throttling/rate-limiting and the rest (free-form,
    vender specific defintion).  The free-form part is stored as key/value pairs
    as special (under the scope 'QoS_specs:') extra_specs of a volume type, and
    the rate-limit control info is stored as part of specification for types (as
    new columns for volume_types table).
    
    Changes:
     - Add following 7 columns to volume_types table for rate-limit requirements
     for volume types.
      * total_bytes_sec: total throughput limit in bytes per second. This cannot
     appear with read_bytes_sec or write_bytes_sec.
      * read_bytes_sec: read throughput limit in bytes per second.
      * write_bytes_sec: write throughput limit in bytes per second.
    
      * total_iops_sec: total I/O operations per second. This cannot appear with
     read_iops_sec or write_iops_sec.
      * read_iops_sec: read I/O operations per second.
      * write_iops_sec: write I/O operations per second.
    
      * 'control_location' is to store the value where admin would like the QoS
     policy to be enforced, currently these three values are considered valid:
     'front-end' (Nova Compute), 'back-end' (Cinder back-end), 'both'.
    
     - 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 rate_limit info.
     - Modify volume_types.create() to accept rate-limit info and do the checks.
     - Add 'qos_specs' to request_specs and filter properties for a volume
     create request.
     - Add rate-limit info to data structure when initialize_connection()
    
    DocImpact
    
    implement blueprint: pass-ratelimit-info-to-nova
    
    Change-Id: Iabc61b941aaff10395b30e2045e3421369a317e2

Automatically generated bug (please review):
https://bugs.launchpad.net/bugs/1202767