On 11/06/2015 06:28 PM, Tim Hinrichs wrote:
Congress allows users to write a policy that executes an action under
certain conditions.
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.
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.
Sounds like Mistral and Congress are competing here, then. Maybe we
should merge those efforts.
Happy to talk more.
Tim
On Fri, Nov 6, 2015 at 9:17 AM Doug Hellmann <d...@doughellmann.com
<mailto:d...@doughellmann.com>> wrote:
Excerpts from Dolph Mathews's message of 2015-11-05 16:31:28 -0600:
> On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann
<d...@doughellmann.com <mailto:d...@doughellmann.com>> wrote:
>
> > Excerpts from Clint Byrum's message of 2015-11-05 10:09:49 -0800:
> > > 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.
> > >
> > > 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]
> >
> > Following the pattern of Kite's naming, I think a Dirigible is a
> > better way to get users into the cloud. :-)
> >
>
> lol +1
>
> Is this use case specifically for keystone-to-keystone, or for
federation
> in general?
The use case I had in mind was actually signing up a new user for
a cloud (at Dreamhost that meant enabling a paid service in their
account in the existing management tool outside of OpenStack). I'm not
sure how it relates to federation, but it seems like that might
just be
another trigger for something similar, though not exactly the same? A
federated user would also presumably need things like a default
network,
for example, though it may not need anything added to the keystone
database.
> As an outcome of the Vancouver summit, we had a use case for
mirroring a
> federated user's project ID from the identity provider cloud to
the service
> provider cloud. The goal would be that a user can burst into a
second cloud
> and immediately receive a token scoped to the same project ID
that they're
> already familiar with (which implies a role assignment of some
sort; for
> example, member). That would have to be done in real time
though, not by a
> secondary service.
>
> And with shadow users, we're looking at creating an identity
(basically,
> nothing but a user_id) in the second cloud anyway. And as another
> consequence of shadow users, they wouldn't be getting a
"federated token"
> of any sort, but rather a simpler, local token, referencing a local
> identity (the user_id that was just created automatically).
>
> Adam, does any of this align with your use case?
>
> >
> > 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://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://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
__________________________________________________________________________
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
