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