Open Stack

-----Original Message-----
From: Clint Byrum <clint at fewbar.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>>
Date: September 29, 2014 at 16:17:39
To: openstack-dev <openstack-dev at lists.openstack.org>>
Subject:  Re: [openstack-dev] [keystone][swift] Has anybody considered storing tokens in Swift?

> Excerpts from Clay Gerrard's message of 2014-09-29 16:05:14 -0700:
> > On Mon, Sep 29, 2014 at 2:53 PM, Chmouel Boudjnah  
> > wrote:
> >
> > >
> > >
> > > eventual consistency will only affect container listing and I don't think
> > > there is a need for container listing in that driver.
> > >
> > >
> > well now hold on...
> >
> > if you're doing an overwrite in the face of server failures you could still
> > get a stale read if a server with an old copy comes back into the fray and
> > you read before replication sorts it out, or read a old version of a key
> > you deleted....
>  
> For tokens, there are really only two answers that matter:
>  
> * does ID==X exist? * has ID==X been revoked?
>
> I think as long as you have a separate container for revocations and
> tokens, then resurrections would be fine. The records themselves would
> be immutable so edits aren't a problem.

This isn’t exactly true. In the case of certain actions (user/project/domain/role delete, user password change, and a number of other ones) you need to be able to find all tokens associated to that entity so they can be revoked (if you’re not using revocation events). This likely means for this type of backend revocation events are a requirement (eliminates the need to list out each token id/provide a way to lookup a token based upon the entity being acted upon) and the ‘enumerated’ token indexes should not be supported. 

—Morgan