Memcache token backend issue upgrading from Grizzly

[Kieran Spear]

Noticed a possible upgrade issue with the pluggable token provider change:
https://github.com/openstack/keystone/commit/c238ace30981877e5991874c5b193ea7d5107419#L12L121

If old PKI tokens still live in a usertoken- index value in memcache, keystone will try to use them as a key to get the actual token. Since they're > 256 bytes this will likely raise an error and make token creation fail for any user with an old token.

[Dolph Mathews (dolph)]

I'm not clear on how to reproduce this (or if you've actually produced an error?)

[Kieran Spear (kspear)]

This is hypothetical at this point, but I'll explain further:

usertokens-<user_id> looks like this in a grizzly memcache server:

"MIICfQYJK...", "MIIasdfjncoie...","MIIconiwec..."

where the length of each encoded token string is around 4k.

The change above in master will do the following when that Grizzly deployment is upgraded to Havana:

    token_list = jsonutils.loads('[%s]' % record) <--- record = self.client.get('usertokens-x')
    for token_i in token_list:
        ptk = self._prefix_token_id(token_i) <--- ptk = "token-MIICfQYJK..."
        token_ref = self.client.get(ptk)

(Pdb) mc.get('token-MIICfQYJK..............................')
*** MemcachedKeyLengthError: Key length is > 250

Which is basically what happened in:
https://bugs.launchpad.net/keystone/+bug/1119641

[Dolph Mathews (dolph)]

This looks like it was fixed long ago - IIRC we use a hash of the token as a memcache key. Leaving as Incomplete in case someone can correct me.

[Launchpad Janitor (janitor)]

[Expired for Keystone because there has been no activity for 60 days.]