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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
