<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class="">
<div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 06 Nov 2015, at 00:09, Clint Byrum <<a href="mailto:clint@fewbar.com" class="">clint@fewbar.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Excerpts from Doug Hellmann's message of 2015-11-05 09:51:41 -0800:<br class=""><blockquote type="cite" class="">Excerpts from Adam Young's message of 2015-11-05 12:34:12 -0500:<br class=""><blockquote type="cite" class="">Can people help me work through the right set of tools for this use case <br class="">(has come up from several Operators) and map out a plan to implement it:<br class=""><br class="">Large cloud with many users coming from multiple Federation sources has <br class="">a policy of providing a minimal setup for each user upon first visit to <br class="">the cloud: Create a project for the user with a minimal quota, and <br class="">provide them a role assignment.<br class=""><br class="">Here are the gaps, as I see it:<br class=""><br class="">1. Keystone provides a notification that a user has logged in, but <br class="">there is nothing capable of executing on this notification at the <br class="">moment. Only Ceilometer listens to Keystone notifications.<br class=""><br class="">2. Keystone does not have a workflow engine, and should not be <br class="">auto-creating projects. This is something that should be performed via <br class="">a Heat template, and Keystone does not know about Heat, nor should it.<br class=""><br class="">3. The Mapping code is pretty static; it assumes a user entry or a <br class="">group entry in identity when creating a role assignment, and neither <br class="">will exist.<br class=""><br class="">We can assume a special domain for Federated users to have per-user <br class="">projects.<br class=""><br class="">So; lets assume a Heat Template that does the following:<br class=""><br class="">1. Creates a user in the per-user-projects domain<br class="">2. Assigns a role to the Federated user in that project<br class="">3. Sets the minimal quota for the user<br class="">4. Somehow notifies the user that the project has been set up.<br class=""><br class="">This last probably assumes an email address from the Federated <br class="">assertion. Otherwise, the user hits Horizon, gets a "not authenticated <br class="">for any projects" error, and is stumped.<br class=""><br class="">How is quota assignment done in the other projects now? What happens <br class="">when a project is created in Keystone? Does that information gets <br class="">transferred to the other services, and, if so, how? Do most people use <br class="">a custom provisioning tool for this workflow?<br class=""><br class=""></blockquote><br class="">I know at Dreamhost we built some custom integration that was triggered<br class="">when someone turned on the Dreamcompute service in their account in our<br class="">existing user management system. That integration created the account in<br class="">keystone, set up a default network in neutron, etc. I've long thought we<br class="">needed a "new tenant creation" service of some sort, that sits outside<br class="">of our existing services and pokes them to do something when a new<br class="">tenant is established. Using heat as the implementation makes sense, for<br class="">things that heat can control, but we don't want keystone to depend on<br class="">heat and we don't want to bake such a specialized feature into heat<br class="">itself.<br class=""><br class=""></blockquote><br class="">I agree, an automation piece that is built-in and easy to add to<br class="">OpenStack would be great.<br class=""><br class="">I do not agree that it should be Heat. Heat is for managing stacks that<br class="">live on and change over time and thus need the complexity of the graph<br class="">model Heat presents.<br class=""><br class="">I'd actually say that Mistral or Ansible are better choices for this. A<br class="">service which listens to the notification bus and triggered a workflow<br class="">defined somewhere in either Ansible playbooks or Mistral's workflow<br class="">language would simply run through the "skel" workflow for each user.<br class=""><br class="">The actual workflow would probably almost always be somewhat site<br class="">specific, but it would make sense for Keystone to include a few basic ones<br class="">as "contrib" elements. For instance, the "notify the user" piece would<br class="">likely be simplest if you just let the workflow tool send an email. But<br class="">if your cloud has Zaqar, you may want to use that as well or instead.<br class=""></div></div></blockquote><br class=""></div><div>Mistral can do a workflow part, create what’s needed, send emails/sms etc.</div><div>What it’s missing now is the way of listening Keystone events. We recently</div><div>created a BP [1] after the summit in Tokyo which is related to this demand</div><div>by its design meaning that it needs a special component that can listen to</div><div>different types of events (like “VM is created”, “User logged in”) and react</div><div>on them.</div><div><br class=""></div><div>So in other words, we need a new trigger in Mistral that would start</div><div>workflows. Actually it doesn’t have to belong to Mistral, it can be just a separate</div><div>component that could tell Mistral to run certain workflow.</div><div><br class=""></div><div>If this is done, it seems like Keystone doesn’t need to depend neither on Mistral</div><div>nor anything else like Heat.</div><div><br class=""></div><div>[1] <a href="https://blueprints.launchpad.net/mistral/+spec/mistral-resource-waiting-actions" class="">https://blueprints.launchpad.net/mistral/+spec/mistral-resource-waiting-actions</a></div><div><br class=""></div><br class=""></body></html>