fernet memcache performance regression

[Brant Knudson]

Fernet token validation performance got worse in mitaka vs in liberty. This is because it's not using memcache to cache the token anymore.

[Samuel de Medeiros Queiroz (samueldmq)]

https://review.openstack.org/#/c/326234

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/326234
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=9c89e07b11afa2e12c97d0af514ce5fcc04e2ac3
Submitter: Jenkins
Branch: master

commit 9c89e07b11afa2e12c97d0af514ce5fcc04e2ac3
Author: Henry Nash <email address hidden>
Date: Tue Jun 7 06:34:21 2016 +0100

    Revert to caching fernet tokens the same way we do UUID

    In Liberty we used to cache the whole token at the provider manager
    validate token call. However, in Mitaka we changed this, for
    non-persistent tokens (e.g. fernet), to instead attempt to cache
    the individual components that make up the token. This change caused
    validating a fernet token to become 5 times slower than the same
    operation in Liberty (as well as UUID in both releases).

    This patches re-instates full-token caching for fernet. This should be
    considered somewhat of a bandaid to redress the performance
    degredation, while we work to restructure our token issuance
    and validation to simplify the multiple code paths.

    In terms of invalidation of such a cache, this change effectively
    reverts to the Liberty approach where anything logged to the
    revokation manager will still cause validaiton of the token to fail
    (this is checked for all token types). However, the alternate (and
    confusingly additonal) "direct" invalidation of the cache via
    the pesistance manager will, like in Liberty, not have any
    effect with cached fernet tokens. As far as I can tell, all
    situations where we currently want a token revoked will send
    this information to both the revoke and persistance managers,
    hence this change should not result in any tokens remaining
    valid when they shouldn't.

    Closes-Bug: #1590179
    Change-Id: I80371746735edac075eec9986e89b54b66bc47cb

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/327381

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/327381
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=a878664f5dbf08626a796e8cfa6fac88cb9e256a
Submitter: Jenkins
Branch: stable/mitaka

commit a878664f5dbf08626a796e8cfa6fac88cb9e256a
Author: Henry Nash <email address hidden>
Date: Tue Jun 7 06:34:21 2016 +0100

    Revert to caching fernet tokens the same way we do UUID

    In Liberty we used to cache the whole token at the provider manager
    validate token call. However, in Mitaka we changed this, for
    non-persistent tokens (e.g. fernet), to instead attempt to cache
    the individual components that make up the token. This change caused
    validating a fernet token to become 5 times slower than the same
    operation in Liberty (as well as UUID in both releases).

    This patches re-instates full-token caching for fernet. This should be
    considered somewhat of a bandaid to redress the performance
    degredation, while we work to restructure our token issuance
    and validation to simplify the multiple code paths.

    In terms of invalidation of such a cache, this change effectively
    reverts to the Liberty approach where anything logged to the
    revokation manager will still cause validaiton of the token to fail
    (this is checked for all token types). However, the alternate (and
    confusingly additonal) "direct" invalidation of the cache via
    the pesistance manager will, like in Liberty, not have any
    effect with cached fernet tokens. As far as I can tell, all
    situations where we currently want a token revoked will send
    this information to both the revoke and persistance managers,
    hence this change should not result in any tokens remaining
    valid when they shouldn't.

    Closes-Bug: #1590179
    Change-Id: I80371746735edac075eec9986e89b54b66bc47cb
    (cherry picked from commit 9c89e07b11afa2e12c97d0af514ce5fcc04e2ac3)

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/keystone 9.1.0 release.

[Davanum Srinivas (DIMS) (dims-v)]

This issue was fixed in the openstack/keystone 10.0.0.0b2 development milestone.