Open Stack

Excerpts from Adam Young's message of 2015-11-05 15:14:03 -0500:
> On 11/05/2015 01:09 PM, Clint Byrum wrote:
> > 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.
> It would be a simpler template than most, but I'm trying to avoid adding 
> additional complexity here.
> 
> >
> > 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]
> 
> I really do not want it to be a new project, but rather I think it 
> should be a mapping of the capabilities of the existing projects.
> 
> 
> We had discussed Mistral in Vancouver as the listener.  Would it make 
> sense to have Keystone notify Mistral, and then Mistral kick off the 
> workflow?

Mistral would need to catch the event and take action on behalf of the
new tenant with some sort of admin rights. Is that possible now?

> 
> The one issue I waffle on is whether Keystone itself should be 
> responsible for the Keystone-specific stuff, as part of the initial log 
> in, and thus give an immediate response to the user upon first 
> authentication.

For the federation case that may make sense. For setting up a new
tenant or user, it may not.

> 
> 
> Alternatively, we could provide a feedback in Horizon etc letting the 
> user know that the process is underway, and even letting them add an 
> email address for the callback if one cannot be deduced from the WebUI.
> 
> 
> Would it male more sense to have this a Horizon-driven workflow, using 
> an unscoped Federation token?

The fact that we can't quite figure out which existing service should do
this is what makes me think it is a new service with a very simple
feature set.

Doug

> 
> >
> > [1] https://goo.gl/photos/EML6EPKeqRXioWfd8 (that was my front yard..)
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>