On Wed, Sep 10, 2014 at 9:14 AM, Sean Dague <s...@dague.net> wrote: > Going through the untriaged Nova bugs, and there are a few on a similar > pattern: > > Nova operation in progress.... takes a while > Crosses keystone token expiration time > Timeout thrown > Operation fails > Terrible 500 error sent back to user > > It seems like we should have a standard pattern that on token expiration > the underlying code at least gives one retry to try to establish a new > token to complete the flow, however as far as I can tell *no* clients do > this. > > I know we had to add that into Tempest because tempest runs can exceed 1 > hr, and we want to avoid random fails just because we cross a token > expiration boundary. > > Anyone closer to the clients that can comment here? > > -Sean > > Currently, a service with a token can't always refresh a new token, because the service doesn't always have the user's credentials (which is good... the service shouldn't have the user's credentials), and even if the credentials were available the service might not be able to use them to authenticate (not all authentication is done using username and password).
The most obvious solution to me is to have the identity server provides an api where, given a token, you can get a new token with an expiration time of your choice. Use of the API would be limited to service users. When a service gets a token that it wants to send on to another service it first uses the existing token to get a new token with whatever expiration time it thinks would be adequate. If the service knows that it's done with the token it will hopefully revoke the new token to keep the token database clean. The only thing missing from the existing auth API for getting a token from a token is being able to set the expiration time -- https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#authentication-authentication . Keystone will also have to be enhanced to validate that if the token-from-token request has a new expiration time the requestor has the required role. - Brant
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev