Open Stack

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

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

    Add rate limit columns to volume_types table
    
    This is part of the effort to implement client-side volume rate limiting
    feature. The idea of client-side volume rate limiting is quite simple: Cinder
    stores rate-limiting parameters in for each volume, and then when Nova asks
    for connection infomration of volume, Cinder sends back rate limiting
    parameters so that Nova can apply to its side via virtualization layer. Take
    KVM hypervisor (or libvirt virt layer) for example: with libvirt later than
    0.9.8, it's able to put following rate limit controls of a block device for
    VM:
    
      * 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.
    
    Note that while it's possible for Cinder to set the granularity of rate limit
    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 in this patch is to bond rate limiting with volume
    types. So Cinder admin can create various volume types with different rate
    limit controls, and volumes of same volume type have same rate limit
    parameters.
    
    To store rate limit parameters with volume types also have two different
    options: 1) extend volume type table itself and add new columns for rate limit;
    2) use volume_type_extra_spec to store rate limit parameters. While the latter
    design seems to have lowest impact of Cinder code, it does bring in new
    challenges: Cinder volume manager needs an fixed way (i.e. doesn't reply on how
    admin create a volume type) to retrieve rate limiting parameters for volumes,
    but extra specs are dynamic by nature (all defined by admin). Therefore, this
    patch takes first approach to store rate limiting paramenters, that's adding
    new columns to volume_types table. It's generic description of how client (and
    /or back-end) should limit throughput/IOPS of volumes, and by default, all rate
    limiting parameters are set to zero, which means there's no rate limit of
    existing volumes.
    
    This patch changes the internal API interface for creating volume types, so no
    impact of compatibility at all. The rest part of the changes needed in Cinder
    are:
     * enable volume manager/driver to read and send rate limit parameters to Nova
     in initliaize_connection() call;
     * allow type_manage API extension to process rate limit parameters;
     * enable cinder client to process rate limit parameters when creating new
     volume types.
    
    DocImpact
    
    partically implement blueprint: pass-ratelimit-info-to-nova
    
    Change-Id: Iabc61b941aaff10395b30e2045e3421369a317e2