<div dir="ltr"><div>They shouldn't be combined because they can each be used without the other. That is, they each stand on their own.</div><div><br></div>Congress can be used for monitoring or delegating policy without attempting to correct violations (i.e. without needing workflows).<div><br></div><div>Mistral can be used to make complex changes without writing a policy. </div><div><br></div><div>Tim</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 9, 2015 at 8:57 AM Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div>On 11/09/2015 10:57 AM, Tim Hinrichs
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Congress happens to have the capability to run a
script/API call under arbitrary conditions on the state of other
OpenStack projects, which sounded like what you wanted. Or did
I misread your original question?
<div><br>
</div>
<div><span style="line-height:1.5">Congress and Mistral are
definitely not competing. </span>Congress lets people
declare which states of the other OpenStack projects are
permitted using a general purpose policy language, but it does
not try to make complex changes (often requiring a workflow)
to eliminate prohibited states. Mistral lets people create a
workflow that makes complex changes to other OpenStack
projects, but it doesn't have a general purpose policy
language that describes which states are permitted. <span style="line-height:1.5">Congress and Mistral are
complementary, and each can stand on its own.</span></div>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
And why should not these two things be in a single project?</div><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Tim</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Mon, Nov 9, 2015 at 6:46 AM Adam Young <<a href="mailto:ayoung@redhat.com" target="_blank"><a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a></a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 11/06/2015 06:28 PM, Tim Hinrichs wrote:<br>
</div>
<blockquote 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>
</div>
<div text="#000000" bgcolor="#FFFFFF"> Sounds like Mistral and
Congress are competing here, then. Maybe we should merge
those efforts.</div>
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote 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 href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</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 href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</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 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 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 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 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 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></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a 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 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></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a 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 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>