[openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

Clint Byrum clint at fewbar.com
Thu Nov 5 18:09:49 UTC 2015


Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800:
> 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.
> 

I agree, an automation piece that is built-in and easy to add to
OpenStack would be great.

I do not agree that it should be Heat. Heat is for managing stacks that
live on and change over time and thus need the complexity of the graph
model Heat presents.

I'd actually say that Mistral or Ansible are better choices for this. A
service which listens to the notification bus and triggered a workflow
defined somewhere in either Ansible playbooks or Mistral's workflow
language would simply run through the "skel" workflow for each user.

The actual workflow would probably almost always be somewhat site
specific, but it would make sense for Keystone to include a few basic ones
as "contrib" elements. For instance, the "notify the user" piece would
likely be simplest if you just let the workflow tool send an email. But
if your cloud has Zaqar, you may want to use that as well or instead.

Adding Mistral here to see if they have some thoughts on how this
might work.

BTW, if this does form into a new project, I suggest naming it
Skeleton[1]

[1] https://goo.gl/photos/EML6EPKeqRXioWfd8 (that was my front yard..)



More information about the OpenStack-dev mailing list