<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><font face="Monaco">I am in the full agreement with the proposed approach (risked to copy below, let's see if email handles your diagrams): </font><div><font face="Monaco"><br></font></div><div><div>* Single Engine handles multiple executions asynchronously, in non-blocking way.</div><div>* Persistence access only from API and/or Engine, Engine writes, API reads. </div><div>* Action runes don't talk to DB - it's very simple protocol and queue is perfectly fine. </div><div>* This is scalable and as fault tolerant as underlying DB and Queue. Engine restart is no loss of info with right persistense; ActionRunner restart  is a lost of Action, which can fail for 100 other reasons thus expected, and with the right retry policy potentially recoverable. </div><div><br></div><div>I'll inline minor points in the etherpad. </div><div><br></div><div><font face="Monaco"><br></font></div><div><font face="Monaco"><br>             API     Engine    Queue    Database        Workers<br>              |       |   |     | |         |            |   |<br>    -------> +-+      |   |     | |         |            |   |<br>             |S|      |   |     | |         |            |   |<br>             |t| --> +-+  |     | |         |            |   |<br>             |a|     | | < - - - - - - - -> |            |   |<br>             |r|     | | - - - -> t - - - - - - - - - > +-+  |<br>             |t| <-- +-+  |     | |         |           | |  |<br>    <------- +-+      |   |     | |         |           | |  |<br>              |       |  +-+ <- r <- - - - - - - - - -  +-+  |<br>    -------> +-+      |  | | <- - - - - - > R            |   |<br>             |I|      |  | | - -> t - - - - - - - - - > +-+  |<br>             |n|      |  | | - -> t - - - - - - - - - - - > +-+<br>             |f|      |  +-+    | |         |           | | | |<br>             |o| <- - - - - - - - - - - - > |           | | | |<br>    <------- +-+      |  +-+ <- r <- - - - - - - - - - -+-+ | |<br>              |       |  | | <- - - - - - > R            |  | |<br>    -------> +-+      |  +-+    | |         |            |  | |<br>             |S| --> +-+  |     | |         |            |  | |<br>             |t|     | | <- - - - - - - - > |            |  | |<br>             |o| <-- +-+  |     | |         |            |  | |<br>             |p|      |  +-+ <- r < - - - - - - - - - - - - +-+<br>    <------- +-+      |  | | <- - - - - - > R            |   |<br>              |       |  |%|    | |         |            |   |<br>              |       |  +-+    | |         |            |   |<br>              |       |   |     | |         |            |   |<br></font><div><br></div><div><br><div><div>On Mar 31, 2014, at 4:09 AM, Kirill Izotov <<a href="mailto:enykeev@stackstorm.com">enykeev@stackstorm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
                <div>
                    <div>I have an idea regarding engine design i want to share with you. But first, it seems like we need a small overview of the current implementations.</div><div><br></div><div>I'm not sure how ML will react on a bunch of ASCII graphs, so here is an etherpad: <a href="https://etherpad.openstack.org/p/mistral-engine-overview-and-proposal">https://etherpad.openstack.org/p/mistral-engine-overview-and-proposal</a></div><div><br></div><div>What do you think, guys, is this the way to go?</div>
                </div>
                <div><div><br></div><div>-- </div><div>Kirill Izotov<br></div><div><br></div></div>
            _______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></div></div></body></html>