python-novaclient: os_cache doesn't refresh the cache on token expiry

[Nicolas Simonds]

When using os_cache in novaclient, there is no provision for refreshing the cache if the cached token is expired. This should be fixed.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/48376

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/35526
Committed: http://github.com/openstack/python-novaclient/commit/9ff60119edd9263319d8d9cc749aaf54b44863d0
Submitter: Jenkins
Branch: master

commit 9ff60119edd9263319d8d9cc749aaf54b44863d0
Author: Nicolas Simonds <email address hidden>
Date: Wed Jul 3 11:08:41 2013 -0700

    if we have a valid auth token, use it instead of generating a new one

    If authenticating with a valid token (i.e., token auth, not
    username/password auth), novaclient would instruct keystone to issue
    a new token with an identical expiry to the one used, and pivot
    onto it. This makes it appear as though Nova is leaking Keystone
    tokens.

    Since there's zero benefit to issuing a new token that is ostensibly
    identical to the perfectly good token used to authenticate, make
    novaclient keep using the token it already has after successful
    validation, and not issue a new one.

    This patch set adds a new pair of tests to the
    AuthenticateAgainstKeystoneTests class, which parrot the current
    authentication pass/fail tests, but exercise the new code paths

    Also adds a fix by Joe Gordon to make os_cache work correctly.

    Change-Id: Ic4f0e6d506d8d81f0b1d46138e7e19d3b3392e1d
    Fixes: Bug 1197201
    Related-Bug: 1214658

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/48376
Committed: http://github.com/openstack/python-novaclient/commit/8eed73ce20ff0808d350fc9af66d6ba55ebda017
Submitter: Jenkins
Branch: master

commit 8eed73ce20ff0808d350fc9af66d6ba55ebda017
Author: Morgan Fainberg <email address hidden>
Date: Wed Sep 25 19:01:13 2013 -0700

    Add-in some re-auth logic when using os_cache

    When using os_cache for the auth_token, if username and password
    are available when a token fails to validate/authenticate, attempt
    a reauth behind the scenes.

    The helper object for stashing the auth_token doesn't handle flushing
    the cache. This is valid behavior because the result would be the
    same as if a bad username/password were issued (401 Unauthorized).

    Fixes-bug: 1214658
    Change-Id: I107fc999610bb7638cefcb5d195aeafdcd663ca6