Comment 3 for bug 1202952

I'm trying to follow along but I'm having to make a few assumptions documented below. Please verify!

First, I assume "keystone/token/backends.py" is intended to refer to "keystone/token/backends/memcache.py".

Second, all the line numbers in the code excerpts appear to refer to the current master branch (not stable/grizzly?).

Those two excerpts on master:

1. https://github.com/openstack/keystone/blob/53ed50ddd0cdebd1b6329f47caac3c8d8b41cd7e/keystone/token/backends/memcache.py#L166-L181

2. https://github.com/openstack/keystone/blob/53ed50ddd0cdebd1b6329f47caac3c8d8b41cd7e/keystone/token/backends/memcache.py#L208-L212

The same two excerpts on stable/grizzly:

1. https://github.com/openstack/keystone/blob/76a94c68d621c893941a817d36f8ddbe9559dbde/keystone/token/backends/memcache.py#L87-L102

2. https://github.com/openstack/keystone/blob/76a94c68d621c893941a817d36f8ddbe9559dbde/keystone/token/backends/memcache.py#L129-L133

Anyway, attempting to reproduce on each branch results in the following responses from GET /v2.0/tokens/revoked:

https://gist.github.com/dolph/899226d3b774787a2ad5

So, the actual content of the response changes quite radically from the entire signed token in stable/grizzly to just a hash in master. In other words, we've introduced a backwards-incompatible API change between the two branches.

While I would prefer to revise the client to handle both responses, we can't guarantee that keystoneclient is the only consumer of that API. It's not very attractive, but the only viable option I see is to revert the change in master, and publish entire signed tokens in the token revocation list.

I didn't test against folsom, but it's safe to assume that the responses from both folsom and grizzly are the same.