Open Stack

On Thu, 11 Sep 2014 03:00:02 PM Duncan Thomas wrote:
> On 11 September 2014 03:17, Angus Lees <gus at inodes.org> wrote:
> > (As inspired by eg kerberos)
> > 2. Ensure at some environmental/top layer that the advertised token
> > lifetime exceeds the timeout set on the request, before making the
> > request.  This implies (since there's no special handling in place)
> > failing if the token was expired earlier than expected.
> 
> We've a related problem in cinder (cinder-backup uses the user's token
> to talk to swift, and the backup can easily take longer than the token
> expiry time) which could not be solved by this, since the time the
> backup takes is unknown (compression, service and resource contention,
> etc alter the time by multiple orders of magnitude)

Yes, this sounds like another example of the cross-service problem I was 
describing with refreshing the token at the bottom layer - but I disagree that 
this is handled any better by refreshing tokens on-demand at the bottom layer.

In order to have cinder refresh the token while talking to swift, it needs to 
know the user's password (ouch - why even have the token) or have magic token 
creating powers (in which case none of this matters, because cinder can just 
create tokens any time it wants).

As far as I can see, we either need to be able to 1) generate tokens that _do_ 
last "long enough", 2) pass user+password to cinder so it is capable of 
creating new tokens as necessary, or 3) only perform token-based auth once at 
the start of a long cinder<->glance workflow like this, and then use some sort 
of limited-scope-but-unlimited-time "session token" for follow-on requests.

I think I'm advocating for (1) or (3), and (2) as a distant third.


... Unless there's some other option here?  Your dismissal above sounded like 
there was already a solution for this - what's the current solution?

-- 
 - Gus