Open Stack

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

Log:
commit e6fb05ef28561ae5f31d4ee51d41d3165937e743
Author: Morgan Fainberg <m at metacloud.com>
Date:   Wed May 22 18:40:57 2013 -0700

    New Revocation List Caching/Handling
    
    Implements a new mechanism for handling revocation lists so that
    proper caching can be done independantly of the token driver. There
    are three provided revocation-list drivers: memcache, sql, and kvs.
    
    SQL revocation-list driver is a simple passthrough driver than
    mimics the previous behavior, relying on the SQL DB to provide all
    of the relevant information.
    
    KVS revocation-list driver works in a similar mechanism to the KVS
    Token driver and will result in unreliable results when running
    Keystone under HTTPD/gunicorn/etc because the DictKvs() object is
    instantiated per driver-object and is not shared.  It should be
    sufficient for caching the SQL revocation-list when running under
    eventlet (or when running the kvs token driver).
    
    Memcache revocation-list driver is the recommended driver to use as
    it will handle the most scenarios.  The memcache driver will also
    handle scenarios where the revoked-token list exceeds the maximum
    page size of the memcache server with the smallest max_item_size.
    This means that the memcache driver has to do some minimal
    construction of the revocation-list from 1 or more pages.  The
    majority of the cases will be loading in 2 pages to report the
    revocation-list, the index page, and the actual JSON page.  In the
    rare case that there is a massive revocation-list.  Memcache driver
    will only reload from memcache if the index page differs from it's
    internal cache.  New UUIDs are used for each page to ensure that
    the internal cache is not stale if the revocation-list is rebuilt.
    
    New Options added
        * (memcache) maximum_revocation_list_pages:
                The maximum number of pages that can be consumed for
                the revocation-list.  This is to set a hard-limit on
                the memory-footprint allowed to be consumed by the
                revocation-list itself.  It is extremely unlikely
                that the revocation-list will ever overflow to a
                2nd or 3rd page.
                Default: 10
    
        * (token) revoked_token_driver:
                string of the new revoked token driver (similar to
                how the token driver works).
                Default:
                    keystone.token.revocation.backends.kvs.Revocation
    
    DocImpact: New Options / New Driver for Revocation Handling
    
    bp cache-token-revocations
    
    Change-Id: I6c062bbe4bd6e90dc585d3e207d00f2461cfb8bd