Open Stack

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

Log:
commit 2bcdb2057188a1a1bd1731ff713631e8a30e4f20
Author: Russell Bryant <rbryant at redhat.com>
Date:   Mon Jun 10 21:18:37 2013 -0400

    Add rpc client side version control.
    
    This is a first pass at client side version control for rpc.  It allows
    you to configure a max version of messages that clients are allowed to
    send.  You can find one example of how clients need to adapt in the
    conductor rpcapi.  All other changes in rpc apis since the grizzly
    release are not applicable to this.
    
    Some future improvements to this could be reporting the versions
    supported by running services and having that be discoverable via the
    API.  We could also consider allow setting these client side version
    caps via the API.  For now, recommended values for these config
    options while attempting a rolling upgrade will just have to be documented.
    
    The config options allow specifying specific rpc api version numbers if
    desired, but an alias of 'grizzly' is also supported.  So typically at
    the start of a rolling upgrade you'd have:
    
        [upgrade_levels]
        compute=grizzly
        conductor=grizzly
        scheduler=grizzly
        ... etc ...
    
    And as you update all instances of a service, you would remove that bit
    from your configuration across the deployment using your config management
    system of choice.
    
    DocImpact
    
    Implements blueprint rpc-version-control.
    
    Change-Id: I2c0fd6dd7484c87823846d7c31d6525d93cd1b43