Open Stack

On Thu, Oct 11, 2012 at 09:10:34AM -0400, Adam Young wrote:
> On 10/11/2012 01:04 AM, heckj wrote:
> >Hey Adam,
> >
> >Wanted to hit you directly - I wasn't clear on what the semantics were that you're aiming for with a "pre-authenticated" token.
> Hope you don't mind me responding to the mailing list, since I
> suspect most people have these questions.
> 
> 
> >
> >We have somewhat similar critters in handing over some related auth (EC2 credentials, and a variation of that theme for Swift TempAuth).
> >
> >What are the key aspects of how one of these "special tokens" is expected to work? From what I've seen so far, it seems like a token that disobeys or has alternate semantics, but it's not entirely clear to me what they are or what we're trying to get with it? Is this sort of a one-shot token concept?
> 
> Pre auth is not a token, so much as it is a contract:  user A is
> allowed to get a token for user B.  User A needs to be authenticated
> already in order to get a token for user B.  After that, the token
> looks exactly like a token for B that user B got themself.
> 
> I don't see it as one shot.  I see it as a way to let services do
> work for another user at some time in the future.

For the Heat API use case it can't be one shot.  We will require
failover operations for the length of the stack.  Who knows how many
times we might need to perform these actions.

Also to be clear the failure actions right now involve destroying and
recreating the instances involved (the entire stack).  One of the big
issues is that this should be done as the user that originally created
it so that we can maintain quota and billing information.  

There is also a concern that the stack may outlive the keystone user.
I'm not sure this is to be handled with this scheme.

The other thought is to create a per-tenant 'heat high availability'
user that would do the restart on behalf of the tenant.  This would at
least maintain tenant based quotas/billing info.

    Ian