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

Tim Hinrichs tim at styra.com
Wed Nov 11 21:57:27 UTC 2015


Excerpts from Wed, Nov 11, 2015 at 10:14 AM Clint Byrum <clint at fewbar.com>
wrote:

> > 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.
>
>
One problem that I'd imagine Mistral would want to solve if it's picking up
events off the bus and executing workflows is how the operator configures
the event-to-workflow mapping logic.  In Adam's example, the operator would
want to say that every time the 'new-user-login-event' shows up on the bus
that Mistral should kick off the 'create-quota' workflow and the
'create-role' workflow.  In simple cases, this would just be a dictionary,
but what happens if the operator wants to condition workflow execution on
an AND/OR/NOT expression evaluated over state from different projects (e.g.
run 'create-quota' when a new user logs in and that user doesn't already
have a nova quota).

For the operator, the problem becomes more complicated when multiple
OpenStack projects are listening to the bus and kicking off
workflows/scripts/etc. The operator now has N projects to configure
(possibly in different ways) and needs to feel confident that there's not
some (rare) sequence of events that puts OpenStack as a whole into a bad
state because the events/workflows she configured have opposing goals.

The benefit of Congress is that there's one rich, declarative language that
operators can use to control the event-to-workflow mapping.  The operator
dictates which events/states (drawn from any collection of OpenStack
projects) should cause which workflows/templates/APIs (again from any
OpenStack project) to be executed.  And because the mapping is written
declaratively, it's feasible to do some conflict detection.

I'm not arguing that Mistral can't or shouldn't be adapted as was
suggested.  I'm just articulating what Congress brings to the table.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151111/9157420b/attachment.html>


More information about the OpenStack-dev mailing list