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-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ 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