Open Stack

Excerpts from Adam Young's message of 2015-11-05 12:34:12 -0500:
> Can people help me work through the right set of tools for this use case 
> (has come up from several Operators) and map out a plan to implement it:
> 
> Large cloud with many users coming from multiple Federation sources has 
> a policy of providing a minimal setup for each user upon first visit to 
> the cloud:  Create a project for the user with a minimal quota, and 
> provide them a role assignment.
> 
> Here are the gaps, as I see it:
> 
> 1.  Keystone provides a notification that a user has logged in, but 
> there is nothing capable of executing on this notification at the 
> moment.  Only Ceilometer listens to Keystone notifications.
> 
> 2.  Keystone does not have a workflow engine, and should not be 
> auto-creating projects.  This is something that should be performed via 
> a Heat template, and Keystone does not know about Heat, nor should it.
> 
> 3.  The Mapping code is pretty static; it assumes a user entry or a 
> group entry in identity when creating a role assignment, and neither 
> will exist.
> 
> We can assume a special domain for Federated users to have per-user 
> projects.
> 
> So; lets assume a Heat Template that does the following:
> 
> 1. Creates a user in the per-user-projects domain
> 2. Assigns a role to the Federated user in that project
> 3. Sets the minimal quota for the user
> 4. Somehow notifies the user that the project has been set up.
> 
> This last probably assumes an email address from the Federated 
> assertion.  Otherwise, the user hits Horizon, gets a "not authenticated 
> for any projects" error, and is stumped.
> 
> How is quota assignment done in the other projects now?  What happens 
> when a project is created in Keystone?  Does that information gets 
> transferred to the other services, and, if so, how?  Do most people use 
> a custom provisioning tool for this workflow?
> 

I know at Dreamhost we built some custom integration that was triggered
when someone turned on the Dreamcompute service in their account in our
existing user management system. That integration created the account in
keystone, set up a default network in neutron, etc. I've long thought we
needed a "new tenant creation" service of some sort, that sits outside
of our existing services and pokes them to do something when a new
tenant is established. Using heat as the implementation makes sense, for
things that heat can control, but we don't want keystone to depend on
heat and we don't want to bake such a specialized feature into heat
itself.

Doug