Open Stack

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?

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.


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?

>
> [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