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

Clint Byrum clint at fewbar.com
Wed Nov 11 18:11:50 UTC 2015


Excerpts from Zane Bitter's message of 2015-11-11 09:43:43 -0800:
> 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.
> 

Zane I like most of what you said here, and agree with nearly all of it.
I actually started typing a question asking why Zaqar, but I think I
understand, and you can correct me if I'm wrong.

There's a notification bus. It is generally accessible to all of the
things run by the operator if the operator wants it to be. Zaqar is for
communication toward the user, whether from user hosted apps or operator
hosted services. The thing we're discussiong seems entirely operator
hosted, to operator hosted. Which to me, at first, meant we should just
teach Mistral to listen to Keystone notifications and to run workflows
using trusts acquired similarly to the way Heat acquires them.

However, it just ocurred to me that if we teach Mistral to read messages
in a Zaqar queue belonging to a user, then there's no weirdness around
user authentication and admin powers. Messages in a user's queue are
entirely acted on using trusts for that user.

That said, I think this is overly abstracted. I'd rather just see
operator hosted services listen to the notification bus and react to the
notifications they care about. You have to teach Mistral about trusts
either way so it can do things as a user, and having the notification
go an extra step:

Keystone->[notifications]->Zaqar->Mistral

vs.

Keystone->[notifications]->Mistral

Doesn't make a ton of sense to me.

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

I agree 100% on the positioning of Congress vs. Mistral here.



More information about the OpenStack-dev mailing list