Open Stack

Excerpts from Michael Elder's message of 2014-04-04 07:16:55 -0700:
> Opened in Launchpad: https://bugs.launchpad.net/heat/+bug/1302624
> 
> I still have concerns though about the design approach of creating a new 
> project for every stack and new users for every resource. 
> 
> If I provision 1000 patterns a day with an average of 10 resources per 
> pattern, you're looking at 10,000 users per day. How can that scale? 
> 

If that can't scale, then keystone is not viable at all. I like to think
we can scale keystone to the many millions of users level.

> How can we ensure that all stale projects and users are cleaned up as 
> instances are destroy? When users choose to go through horizon or nova to 
> tear down instances, what cleans up the project & users associated with 
> that heat stack? 
> 

So, they created these things via Heat, but have now left the dangling
references in Heat, and expect things to work properly?

If they create it via Heat, they need to delete it via Heat.

> Keystone defines the notion of tokens to support authentication, why 
> doesn't the design provision and store a token for the stack and its 
> equivalent management? 
> 

Tokens are _authentication_, not _authorization_. For the latter, we
need to have a way to lock down access to an individual resource in
Heat. This allows putting secrets in deployments and knowing that only
the instance which has been deployed to will have access to the secrets.
I do see an optimization possible, which is to just create a user for the
box that is given access to any deployments on the box. That would make
sense if users are going to create many many deployments per server. But
even at 10 per server, having 10 users is simpler than trying to manage
shared users and edit their authorization rules.

Now, I actually think that OAUTH tokens _are_ intended to be authorization
as well as authentication, so that is probably where the focus should
be long term. But really, you're talking about the same thing: a single
key lookup in keystone.