<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">Excerpts from Wed, Nov 11, 2015 at 10:14 AM Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> But as Renat mentioned, the part about triggering Mistral workflows from<br>
> a message does not yet exist. As Tim pointed out, Congress could be a<br>
> solution to that (listening for a message and then starting the Mistral<br>
> workflow). That may be OK in the short term, but in the long term I'd<br>
> prefer that we implement the triggering thing in Mistral (since there<br>
> are *lots* of end-user use cases for this too), and have the workflow<br>
> optionally query Congress for the policy rather than having Congress in<br>
> the loop.<br>
><br>
<br>
I agree 100% on the positioning of Congress vs. Mistral here.<br>
<br></blockquote><div><br></div><div>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).<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Tim<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>