-----Original Message-----
From: Clint Byrum <cl...@fewbar.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
Date: September 29, 2014 at 16:17:39
To: openstack-dev <openstack-dev@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. 


OpenStack-dev mailing list

Reply via email to