<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/06/2015 06:28 PM, Tim Hinrichs
wrote:<br>
</div>
<blockquote
cite="mid:CAJjxPADRNYZ94p-ptSNcNB5GN3axATUm+kmr70Eu0-JuNyz=bQ@mail.gmail.com"
type="cite">
<div dir="ltr">Congress allows users to write a policy that
executes an action under certain conditions.
<div>
<div><br>
</div>
<div>The conditions can be based on any data Congress has
access to, which includes nova servers, neutron networks,
cinder storage, keystone users, etc. We also have some
Ceilometer statistics; I'm not sure about whether it's easy
to get the Keystone notifications that you're talking about
today, but notifications are on our roadmap. If the user's
login is reflected in the Keystone API, we may already be
getting that event.</div>
<div><br>
</div>
<div>The action could in theory be a mistral/heat API or an
arbitrary script. Right now we're set up to invoke any
method on any of the python-clients we've integrated with.
We've got an integration with heat but not mistral. New
integrations are typically easy.</div>
</div>
</div>
</blockquote>
<br>
Sounds like Mistral and Congress are competing here, then. Maybe we
should merge those efforts.<br>
<br>
<blockquote
cite="mid:CAJjxPADRNYZ94p-ptSNcNB5GN3axATUm+kmr70Eu0-JuNyz=bQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<div>Happy to talk more.</div>
<div><br>
</div>
<div>Tim</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Nov 6, 2015 at 9:17 AM Doug Hellmann <<a
moz-do-not-send="true" href="mailto:doug@doughellmann.com"><a class="moz-txt-link-abbreviated" href="mailto:doug@doughellmann.com">doug@doughellmann.com</a></a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts
from Dolph Mathews's message of 2015-11-05 16:31:28 -0600:<br>
> On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann <<a
moz-do-not-send="true" href="mailto:doug@doughellmann.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:doug@doughellmann.com">doug@doughellmann.com</a></a>> wrote:<br>
><br>
> > Excerpts from Clint Byrum's message of 2015-11-05
10:09:49 -0800:<br>
> > > Excerpts from Doug Hellmann's message of
2015-11-05 09:51:41 -0800:<br>
> > > > Excerpts from Adam Young's message of
2015-11-05 12:34:12 -0500:<br>
> > > > > Can people help me work through the
right set of tools for this use<br>
> > case<br>
> > > > > (has come up from several Operators)
and map out a plan to implement<br>
> > it:<br>
> > > > ><br>
> > > > > Large cloud with many users coming
from multiple Federation sources<br>
> > has<br>
> > > > > a policy of providing a minimal setup
for each user upon first visit<br>
> > to<br>
> > > > > the cloud: Create a project for the
user with a minimal quota, and<br>
> > > > > provide them a role assignment.<br>
> > > > ><br>
> > > > > Here are the gaps, as I see it:<br>
> > > > ><br>
> > > > > 1. Keystone provides a notification
that a user has logged in, but<br>
> > > > > there is nothing capable of executing
on this notification at the<br>
> > > > > moment. Only Ceilometer listens to
Keystone notifications.<br>
> > > > ><br>
> > > > > 2. Keystone does not have a workflow
engine, and should not be<br>
> > > > > auto-creating projects. This is
something that should be performed<br>
> > via<br>
> > > > > a Heat template, and Keystone does
not know about Heat, nor should<br>
> > it.<br>
> > > > ><br>
> > > > > 3. The Mapping code is pretty
static; it assumes a user entry or a<br>
> > > > > group entry in identity when creating
a role assignment, and neither<br>
> > > > > will exist.<br>
> > > > ><br>
> > > > > We can assume a special domain for
Federated users to have per-user<br>
> > > > > projects.<br>
> > > > ><br>
> > > > > So; lets assume a Heat Template that
does the following:<br>
> > > > ><br>
> > > > > 1. Creates a user in the
per-user-projects domain<br>
> > > > > 2. Assigns a role to the Federated
user in that project<br>
> > > > > 3. Sets the minimal quota for the
user<br>
> > > > > 4. Somehow notifies the user that the
project has been set up.<br>
> > > > ><br>
> > > > > This last probably assumes an email
address from the Federated<br>
> > > > > assertion. Otherwise, the user hits
Horizon, gets a "not<br>
> > authenticated<br>
> > > > > for any projects" error, and is
stumped.<br>
> > > > ><br>
> > > > > How is quota assignment done in the
other projects now? What happens<br>
> > > > > when a project is created in
Keystone? Does that information gets<br>
> > > > > transferred to the other services,
and, if so, how? Do most people<br>
> > use<br>
> > > > > a custom provisioning tool for this
workflow?<br>
> > > > ><br>
> > > ><br>
> > > > I know at Dreamhost we built some custom
integration that was triggered<br>
> > > > when someone turned on the Dreamcompute
service in their account in our<br>
> > > > existing user management system. That
integration created the account<br>
> > in<br>
> > > > keystone, set up a default network in
neutron, etc. I've long thought<br>
> > we<br>
> > > > needed a "new tenant creation" service of
some sort, that sits outside<br>
> > > > of our existing services and pokes them to
do something when a new<br>
> > > > tenant is established. Using heat as the
implementation makes sense,<br>
> > for<br>
> > > > things that heat can control, but we don't
want keystone to depend on<br>
> > > > heat and we don't want to bake such a
specialized feature into heat<br>
> > > > itself.<br>
> > > ><br>
> > ><br>
> > > I agree, an automation piece that is built-in
and easy to add to<br>
> > > OpenStack would be great.<br>
> > ><br>
> > > I do not agree that it should be Heat. Heat is
for managing stacks that<br>
> > > live on and change over time and thus need the
complexity of the graph<br>
> > > model Heat presents.<br>
> > ><br>
> > > I'd actually say that Mistral or Ansible are
better choices for this. A<br>
> > > service which listens to the notification bus
and triggered a workflow<br>
> > > defined somewhere in either Ansible playbooks
or Mistral's workflow<br>
> > > language would simply run through the "skel"
workflow for each user.<br>
> > ><br>
> > > The actual workflow would probably almost
always be somewhat site<br>
> > > specific, but it would make sense for Keystone
to include a few basic<br>
> > ones<br>
> > > as "contrib" elements. For instance, the
"notify the user" piece would<br>
> > > likely be simplest if you just let the workflow
tool send an email. But<br>
> > > if your cloud has Zaqar, you may want to use
that as well or instead.<br>
> > ><br>
> > > Adding Mistral here to see if they have some
thoughts on how this<br>
> > > might work.<br>
> > ><br>
> > > BTW, if this does form into a new project, I
suggest naming it<br>
> > > Skeleton[1]<br>
> ><br>
> > Following the pattern of Kite's naming, I think a
Dirigible is a<br>
> > better way to get users into the cloud. :-)<br>
> ><br>
><br>
> lol +1<br>
><br>
> Is this use case specifically for keystone-to-keystone,
or for federation<br>
> in general?<br>
<br>
The use case I had in mind was actually signing up a new user
for<br>
a cloud (at Dreamhost that meant enabling a paid service in
their<br>
account in the existing management tool outside of OpenStack).
I'm not<br>
sure how it relates to federation, but it seems like that
might just be<br>
another trigger for something similar, though not exactly the
same? A<br>
federated user would also presumably need things like a
default network,<br>
for example, though it may not need anything added to the
keystone<br>
database.<br>
<br>
> As an outcome of the Vancouver summit, we had a use case
for mirroring a<br>
> federated user's project ID from the identity provider
cloud to the service<br>
> provider cloud. The goal would be that a user can burst
into a second cloud<br>
> and immediately receive a token scoped to the same
project ID that they're<br>
> already familiar with (which implies a role assignment of
some sort; for<br>
> example, member). That would have to be done in real time
though, not by a<br>
> secondary service.<br>
><br>
> And with shadow users, we're looking at creating an
identity (basically,<br>
> nothing but a user_id) in the second cloud anyway. And as
another<br>
> consequence of shadow users, they wouldn't be getting a
"federated token"<br>
> of any sort, but rather a simpler, local token,
referencing a local<br>
> identity (the user_id that was just created
automatically).<br>
><br>
> Adam, does any of this align with your use case?<br>
><br>
> ><br>
> > Doug<br>
> ><br>
> > ><br>
> > > [1] <a moz-do-not-send="true"
href="https://goo.gl/photos/EML6EPKeqRXioWfd8"
rel="noreferrer" target="_blank">https://goo.gl/photos/EML6EPKeqRXioWfd8</a>
(that was my front yard..)<br>
> > ><br>
> ><br>
> >
__________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage
questions)<br>
> > Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>