Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Zane Bitter]

On 09/11/15 11:55, Adam Young wrote:

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?


Because they're completely different projects with completely different 
architectures developed by completely different teams that do completely 
different things for completely different groups of users.


This is a bit like saying that Nova and Rally should be a single project 
because they both sometimes make API calls to Cinder. The premise is 
technically true but as an argument... it's not so great.



Arguably, Congress should have implemented their action invocation as a 
hard-coded call to Mistral so as to let users define an arbitrary 
workflow. Instead they made it pluggable and allowed users to specify 
any single API call (provided a plugin existed for it, and the Mistral 
one does not yet). This does duplicate functionality in Mistral in the 
sense that Mistral also has plugins to call OpenStack APIs, which it 
does as a step in a workflow. It's easy to see why they might have 
chosen that - no young project wants to hitch its wagon to any other 
relatively young project because it makes getting adoption that much 
harder. However there's an easy migration path (write a Mistral plugin, 
convert the other actions to one-step workflows, switch over to using 
the Mistral plugin exclusively), so it seems like a perfectly sensible 
decision to me. Merging the projects because of this one tiny bit of 
common functionality would be absurd.


cheers,
Zane.



Tim


On Mon, Nov 9, 2015 at 6:46 AM Adam Young
<ayo...@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
> 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
> 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.
  

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Renat Akhmerov]

> On 09 Nov 2015, at 20:43, Adam Young  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.

I may be wrong on this but the difference is that Mistral provides workflow. 
Meaning you can have a graph of tasks related by conditional logic whereas 
Congress action is something simple like calling a function. Correct me if my 
understanding is wrong. I actually don’t know at this point whether a workflow 
is really needed, IMO it does make sense if we need to create a bunch of heavy 
resources so it should be an HA service managing the process of 
configuring/creating the new tenant. The power of workflow is in automating 
long-running stuff.

But both technologies are missing notifications part now.

Renat Akhmerov
@ Mirantis Inc.



__
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

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Renat Akhmerov]

> On 09 Nov 2015, at 21:57, 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.

+1


__
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

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Renat Akhmerov]

Renat Akhmerov
@ Mirantis Inc.



> On 06 Nov 2015, at 00:09, Clint Byrum  wrote:
> 
> 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.

Mistral can do a workflow part, create what’s needed, send emails/sms etc.
What it’s missing now is the way of listening Keystone events. We recently
created a BP [1] after the summit in Tokyo which is related to this demand
by its design meaning that it needs a special component that can listen to
different types of events (like “VM is created”, “User logged in”) and react
on them.

So in other words, we need a new trigger in Mistral that would start
workflows. Actually it doesn’t have to belong to Mistral, it can be just a 
separate
component that could tell Mistral to run certain workflow.

If this is done, it seems like Keystone doesn’t need to depend neither on 
Mistral
nor anything else like Heat.

[1] 
https://blueprints.launchpad.net/mistral/+spec/mistral-resource-waiting-actions 



__
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

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Renat Akhmerov]

> On 06 Nov 2015, at 03:41, Doug Hellmann  wrote:
> 
> Excerpts from Adam Young's message of 2015-11-05 15:14:03 -0500:
>> On 11/05/2015 01:09 PM, Clint Byrum wrote:
>>> 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.
>> It would be a simpler template than most, but I'm trying to avoid adding 
>> additional complexity here.
>> 
>>> 
>>> 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]
>> 
>> I really do not want it to be a new project, but rather I think it 
>> should be a mapping of the capabilities of the existing projects.
>> 
>> 
>> We had discussed Mistral in Vancouver as the listener.  Would it make 
>> sense to have Keystone notify Mistral, and then Mistral kick off the 
>> workflow?
> 
> Mistral would need to catch the event and take action on behalf of the
> new tenant with some sort of admin rights. Is that possible now?


Taking an action on behalf of the new is possible only if needed credentials
are passed into the workflow. No special magic exists here. I might be missing
something though.


Renat Akhmerov
@ Mirantis Inc.

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Renat Akhmerov]

> On 10 Nov 2015, at 21:29, Renat Akhmerov  wrote:
> 
> 
>> On 09 Nov 2015, at 21:57, 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.
> 
> +1
> 


Btw, that Congress action can be calling Mistral to start a workflow.

Renat Akhmerov
@ Mirantis Inc.


__
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

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Adam Young]

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 > 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
> 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. 

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Tim Hinrichs]

They shouldn't be combined because they can each be used without the
other.  That is, they each stand on their own.

Congress can be used for monitoring or delegating policy without attempting
to correct violations (i.e. without needing workflows).

Mistral can be used to make complex changes without writing a policy.

Tim





On Mon, Nov 9, 2015 at 8:57 AM Adam Young  wrote:

> 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  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 
>> 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 
>>> 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.
>>> > > > > >

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Richard Raseley]

From this operator’s perspective this is exactly the element of community 
culture that, by encouraging the proliferation of projects and tools, is making 
the OpenStack landscape more complex and less {user,operator,architect,business 
decision maker} friendly.

In my opinion, it is essentially a manufactured and completely unnecessary 
distinction. I look forward to the day when, through some yet to be known 
mechanism, we have have a more focused product perspective within the community.

> On Nov 9, 2015, at 10:11 AM, Tim Hinrichs  wrote:
> 
> They shouldn't be combined because they can each be used without the other.  
> That is, they each stand on their own.
> 
> Congress can be used for monitoring or delegating policy without attempting 
> to correct violations (i.e. without needing workflows).
> 
> Mistral can be used to make complex changes without writing a policy.
> 
> Tim
> 
> 
> 
> 
> 
> On Mon, Nov 9, 2015 at 8:57 AM Adam Young  wrote:
> 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  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  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  
>>> > 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
>>> > > > > > 

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Tim Hinrichs]

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.

Tim


On Mon, Nov 9, 2015 at 6:46 AM Adam Young  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 
> 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 
>> 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 

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Adam Young]

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 > 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
> 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
> 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.
> > > > >
> > 

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Clint Byrum]

Excerpts from Richard Raseley's message of 2015-11-09 10:34:26 -0800:
> From this operator’s perspective this is exactly the element of community 
> culture that, by encouraging the proliferation of projects and tools, is 
> making the OpenStack landscape more complex and less 
> {user,operator,architect,business decision maker} friendly.

I'd agree with you that looking at all of the "OpenStack projects" as
"OpenStack" will make you go cross-eyed.

However, I think if you start with the guides and documentation, that
is where the homogeneous, settled parts of the platform reside that some
people might call OpenStack's "product".

Once a thing starts to work well and is accepted by early adopters, it
gets fleshed out documentation, and there's usually not a large decision
tree presented in there by that time.

If, however, you have more aggressive needs, then I think you have to
build on top of that platform and look at the greater landscape with a
focus toward solving specific problems. For instance, autoprovisioning,
and accept that it may not be clear what way works well.

> 
> In my opinion, it is essentially a manufactured and completely unnecessary 
> distinction. I look forward to the day when, through some yet to be known 
> mechanism, we have have a more focused product perspective within the 
> community.
> 
> > On Nov 9, 2015, at 10:11 AM, Tim Hinrichs  wrote:
> > 
> > They shouldn't be combined because they can each be used without the other. 
> >  That is, they each stand on their own.
> > 
> > Congress can be used for monitoring or delegating policy without attempting 
> > to correct violations (i.e. without needing workflows).
> > 
> > Mistral can be used to make complex changes without writing a policy.
> > 
> > Tim
> > 
> > 
> > 
> > 
> > 
> > On Mon, Nov 9, 2015 at 8:57 AM Adam Young  wrote:
> > 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  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  
> >>> 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  
> >>> > 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 

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Tim Hinrichs]

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.

Happy to talk more.

Tim



On Fri, Nov 6, 2015 at 9:17 AM Doug Hellmann  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 
> 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" 

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Doug Hellmann]

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  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 

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Clint Byrum]

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]

[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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Adam Young]

On 11/05/2015 01:09 PM, Clint Byrum wrote:

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.
It would be a simpler template than most, but I'm trying to avoid adding 
additional complexity here.





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]


I really do not want it to be a new project, but rather I think it 
should be a mapping of the capabilities of the existing projects.



We had discussed Mistral in Vancouver as the listener.  Would it make 
sense to have Keystone notify Mistral, and then Mistral kick off the 
workflow?


The one issue I waffle on is whether Keystone itself should be 
responsible for the Keystone-specific stuff, as part of the initial log 
in, and thus give an immediate response to the user upon first 
authentication.



Alternatively, we could provide a feedback in Horizon etc letting the 
user know that the process is underway, and even letting them add an 
email address for the callback if one cannot be deduced from the WebUI.



Would it male more sense to have this a Horizon-driven workflow, using 
an unscoped Federation token?




[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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Dolph Mathews]

On Thu, Nov 5, 2015 at 3:43 PM, Doug Hellmann  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?

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,

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Doug Hellmann]

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. :-)

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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

[Doug Hellmann]

Excerpts from Adam Young's message of 2015-11-05 15:14:03 -0500:
> On 11/05/2015 01:09 PM, Clint Byrum wrote:
> > 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.
> It would be a simpler template than most, but I'm trying to avoid adding 
> additional complexity here.
> 
> >
> > 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]
> 
> I really do not want it to be a new project, but rather I think it 
> should be a mapping of the capabilities of the existing projects.
> 
> 
> We had discussed Mistral in Vancouver as the listener.  Would it make 
> sense to have Keystone notify Mistral, and then Mistral kick off the 
> workflow?

Mistral would need to catch the event and take action on behalf of the
new tenant with some sort of admin rights. Is that possible now?

> 
> The one issue I waffle on is whether Keystone itself should be 
> responsible for the Keystone-specific stuff, as part of the initial log 
> in, and thus give an immediate response to the user upon first 
> authentication.

For the federation case that may make sense. For setting up a new
tenant or user, it may not.

> 
> 
> Alternatively, we could provide a