Renat Akhmerov @ Mirantis Inc.
> On 06 Nov 2015, at 00:09, Clint Byrum <cl...@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>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev