Excerpts from Renat Akhmerov's message of 2015-11-12 07:52:42 -0800: > > > On 12 Nov 2015, at 00:11, Clint Byrum <cl...@fewbar.com> wrote: > > > > 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. > > Mistral uses trusts I think the same way that Heat does. >
Well thats good news. So, keeping things simple, I think this is a case of just being able to let admins set up a workflow that gets run based on notifications, and that would need to include setting the user to run as from content in the notification. __________________________________________________________________________ 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