Open Stack

Renat Akhmerov
@ Mirantis Inc.



> On 06 Nov 2015, at 00:09, Clint Byrum <clint at fewbar.com> 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.
> 
> 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.

Mistral can do a workflow part, create what’s needed, send emails/sms etc.
What it’s missing now is the way of listening Keystone events. We recently
created a BP [1] after the summit in Tokyo which is related to this demand
by its design meaning that it needs a special component that can listen to
different types of events (like “VM is created”, “User logged in”) and react
on them.

So in other words, we need a new trigger in Mistral that would start
workflows. Actually it doesn’t have to belong to Mistral, it can be just a separate
component that could tell Mistral to run certain workflow.

If this is done, it seems like Keystone doesn’t need to depend neither on Mistral
nor anything else like Heat.

[1] https://blueprints.launchpad.net/mistral/+spec/mistral-resource-waiting-actions <https://blueprints.launchpad.net/mistral/+spec/mistral-resource-waiting-actions>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151110/5a89569b/attachment.html>