Open Stack

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

Log:
commit de4a66a2ca746fa4748137f82c392deff401d25d
Author: Zhiteng Huang <zhiteng.huang at intel.com>
Date:   Sat Oct 6 00:08:09 2012 +0800

    Implement filter scheduler
    
    In order to do more sophisticated scheduling (e.g. schedule based on volume
    type), filter scheduler is introduced. Several changes are made to make this
    possible, some of them are similar to the counterpart in Nova:
    
    - add HostState class to host_manager in order to store volume capabilities
    - implement get_volume_stats() method of iSCSIDriver as an example to
    demonstrate how volume backend driver reports capabilities as well as status
    - add scheduler_options.py and 'scheduler_json_config_location' flag to be
    allow loading json configuration file for scheduler at run time
    - port common filters/weights from oslo
    - add capacity weigher (scheduler/weights/capacity.py) for picking up
    target volume backend by weighing free capacity of the host. The default
    behavior is to spread volumes across hosts; by changing the
    'capacity_weight_multiplier' to negative number, volume placing behavior will
    become stacking.
    - add capacity filter which filters those hosts have insufficient storage space
    to serve the request.
    - add 'reserved_percentage' config option to indicate how much space is
    reserved. Capacity reservation is needed when volume resize is enabled.
    - change default scheduler to 'filter.FilterScheduler'.
    - add 'publish_service_capabilities()' method to volume RPC API to allow
    scheduler to have volume service report capabilities. This bumps volume RPC
    API to version 1.1
    
    The implication of this change to storage/backend driver developer:
    - implementation of get_volume_stats() of the driver is now a *MUST*, filter
    scheduler heavily relies on the status/capabilities reported by backend driver
    to makeplacement decision.  To ensure Cinder works seamlessly on the storage
    system, driver should at least report following capabilities/status:
    ----------------------+---------------------------+---------------------------
      Capability/Status   |      Description          |         Example
    ----------------------+---------------------------+---------------------------
     'volume_backend_name'| back-end name, string     | 'Example_Storage_Backend'
    ----------------------+---------------------------+---------------------------
      'vendor_name'       | vendor name, string       | 'OpenStackCinder'
    ----------------------+---------------------------+---------------------------
      'driver_version'    | version, string           |  '1.0a'
    ----------------------+---------------------------+---------------------------
      'storage_protocol'  | supported protocols,      | 'iSCSI', 'RBD', 'FC', 'NFS'
                          | string or list of strings | ['iSCSI', 'NFS', 'FC']
    ----------------------+---------------------------+---------------------------
      'storage_media'     | supported storage medias, |  'SSD', 'SATA HDD', 'RAM'
                          | string or list of strings | ['SSD', 'SAS HDD']
    ----------------------+---------------------------+---------------------------
      'total_capacity_gb' | capacity in GB, integer   |  102400
    ----------------------+---------------------------+---------------------------
      'free_capacity_gb'  | available capacity in GB, |  1000
                          | integer                   |
    ----------------------+---------------------------+---------------------------
    'reserved_percentage' | reserved space in         |  0, 10
                          | percentage, integer       |
    ----------------------+---------------------------+---------------------------
    
    The implication of this change to Cinder administrator:
    - the default setting for filter scheduler should work well with the benefits
    of:
      * being able to fully utilize capacity of backends (driver now has to report
      actul total space and space utilization and scheduler uses these info) not
      limited by the 'max_gigabytes' config option any more;
      * being able to choose placement policy between spreading & stacking for
      volume creation (by modifying the 'capacity_weight_multiplier' in
      CapacityWeigher)
    - with filter scheduler, Cinder is now able to utilize the advanced features/
    capabilities provided by different storage back-ends via: defining different
    volume types with proper extra_specs. Volume types can be considered as sets
    of back-end capabilities requirement.
     For example, a volume type which has 'storage_media':'SSD' key/value pair
    definition in its extra_spec can only be served by those back-ends who report
    they support SSD as storage media. Another example is volume type has 'QoS'
    requirement can only be served by back-ends support QoS.
    
    Note:
    * Currently scheduler makes its decision based on the status and capabilities
    information reported by volume nodes, and these information is stored in memory
    of scheduler process. By default, volume nodes perioidically report status if
    there its status/capabilities changed during the perioid, if (for any reason)
    scheduler missed a few report (fanout) message from volume node, scheduler may
    ignore the volume node. To simply work around this issue, this patch changes
    'volume_force_update_capabilities' to true. More sophisticated way may be
    add on table in DB to record status/capabilities of all volume nodes, like Nova
    does for compute nodes.
    
    implement bp volume-type-scheduler
    
    DocImpact
    
    Change-Id: I8b5305bce3b24bcc85365037356a8f36d0107133