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