[openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation
Adam Young
ayoung at redhat.com
Mon Nov 9 16:55:02 UTC 2015
On 11/09/2015 10:57 AM, Tim Hinrichs wrote:
> 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?
>
> Congress and Mistral are definitely not competing. 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. Congress and Mistral are complementary, and each can stand
> on its own.
And why should not these two things be in a single project?
>
> Tim
>
>
> On Mon, Nov 9, 2015 at 6:46 AM Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
>
> 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
>> <doug at doughellmann.com <mailto:doug at 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
>> <doug at doughellmann.com <mailto:doug at 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-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>> <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151109/ddfafc8b/attachment.html>
More information about the OpenStack-dev
mailing list