Open Stack

I'm in the middle of deploying a keystone cluster to support multiple regions. We were told we wouldn't need rabbit for this case.

Just something to keep in mind. Keystone's kind of unique in that it can be shared between regions.

Thanks,
Kevin
________________________________________
From: Zane Bitter [zbitter at redhat.com]
Sent: Wednesday, November 11, 2015 9:43 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [keystone] [Mistral] [Heat] Autoprovisioning, per-user projects, and Federation

On 10/11/15 11:32, Adam Young wrote:
> On 11/10/2015 10:28 AM, Renat Akhmerov wrote:
>>
>>
>>> On 09 Nov 2015, at 20:43, Adam Young <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.
>> 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.
>
> This does not need to be super complicated; we need a listener that can
> kick off workflows.  If congress is that listener, super.

Listening to what?

If it's the RabbitMQ bus then there has been a lot of talk about having
some service listen to that and emit notifications to actual end-users.
Ceilometer has been mentioned in the context of these discussions. I
would love to see this happen. I know we discussed it in the Horizon
track at Summit, and Heat also has use cases for this.

At the user level, there are many, many use cases that could benefit
from being able to trigger a Mistral workflow from a Zaqar message
(Renat and I have discussed this on a number of occasions), and this is
possibly another.

The two are not mutually exclusive, either - potentially Ceilometer
could be listening on the RabbitMQ bus and emitting notifications to
Zaqar that could be picked up by Mistral. It sounds like that's not
necessary though; Keystone could probably emit the notification wherever
it likes.

> I would think that it would then be
>
> 1. Keystone sends "new federated user" notification out on the message bus.
> 2. Congress Picks up the message and checks policy to see what should be
> done.
> 3. Congress calls Heat to fire off template for autoprovisioning user.

This is the right solution if:
- The user template is somewhat complex
- Congress always needs control over the policy
- All we ever need to do is encapsulated in the Heat template

> It could also be:
>
> 1. Keystone sends "new federated user" notification out on the message bus.
> 2. Murano Picks up the message and checks policy to see what should be
> done.
> 3. Murano calls Heat to fire off template for autoprovisioning user.

Assuming s/Murano/Mistral/, this is the right solution if:

- The user template is somewhat complex
- We want it to also work without Congress in the loop

Another possibility:

1. Keystone sends "new federated user" notification out on the message bus.
2. Mistral picks up the message and checks policy to see what should be
  done.
3. Mistral creates the autoprovisioning user directly.

This is the right solution if:
- Creating the user is no harder than creating a Heat stack
- We want it to also work without Congress in the loop

> You are suggesting it should be:
>
> 1. Keystone sends "new federated user" notification out on the message bus.
> 2. Congress Picks up the message and checks policy to see what should be
> done.
> 3. Congress calls Murano to fire off template for autoprovisioning user.

This is the right solution if:

- Creating the user is no harder than creating a Heat stack
- Congress always needs control over the policy
- The action may need to be customised in ways not encapsulated in a
Heat template

> And, the most complex solution:
>
> 1. Keystone sends "new federated user" notification out on the message bus.
> 2. Congress Picks up the message and checks policy to see what should be
> done.
> 3. Congress calls Murano to fire off template for autoprovisioning user.
> 4. Murano calls Heat to fire off template for autoprovisioning user.

This is the right solution if:
- The user template is somewhat complex
- Congress always needs control over the policy
- The action may need to be customised in ways not encapsulated in a
Heat template


> Personally, I would prefer:
>
> 1. Keystone sends "new federated user" notification out on the message bus.
> 2. Heat Picks up the message and checks policy to see what should be done.
> 3. Heat fires off template for autoprovisioning user.

This is never the right solution ;)

> Why the last:  Heat already exists and already has a message listener.

No it doesn't.


Evaluating against your initial requirements:

 > 1. Creates a user in the per-user-projects domain
 > 2. Assigns a role to the Federated user in that project

This is barely more complicated that just creating a user... it's 50/50
whether Heat is worth using at all here.

 > 3. Sets the minimal quota for the user

Not sure what the API for this looks like, but given that an admin could
presumably want to change the quota later without modifying the Heat
template, this is probably better done by Mistral.

 > 4. Somehow notifies the user that the project has been set up.

Triggering such a notification is bread-and-butter for Mistral.


So Mistral yes, Heat maybe, Congress optional, would argue for:

1. Keystone (or some Rabbit->Zaqar proxy service reading notifications
from Keystone) sends "new federated user" notification out via Zaqar.
2. Mistral picks up the message and checks policy to see what should be
done.
3. Mistral calls either Heat or Keystone to autoprovision user.

But as Renat mentioned, the part about triggering Mistral workflows from
a message does not yet exist. As Tim pointed out, Congress could be a
solution to that (listening for a message and then starting the Mistral
workflow). That may be OK in the short term, but in the long term I'd
prefer that we implement the triggering thing in Mistral (since there
are *lots* of end-user use cases for this too), and have the workflow
optionally query Congress for the policy rather than having Congress in
the loop.

cheers,
Zane.

__________________________________________________________________________
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