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.
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/53ed50ddd0 cdebd1b6329f47c aac3c8d8b41cd7e /keystone/ token/backends/ memcache. py#L166- L181
2. https:/ /github. com/openstack/ keystone/ blob/53ed50ddd0 cdebd1b6329f47c aac3c8d8b41cd7e /keystone/ token/backends/ memcache. py#L208- L212
The same two excerpts on stable/grizzly:
1. https:/ /github. com/openstack/ keystone/ blob/76a94c68d6 21c893941a817d3 6f8ddbe9559dbde /keystone/ token/backends/ memcache. py#L87- L102
2. https:/ /github. com/openstack/ keystone/ blob/76a94c68d6 21c893941a817d3 6f8ddbe9559dbde /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/ 899226d3b774787 a2ad5
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.