<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Thanks Renat for a clear design summary, </div><div>thanks Joshua for the questions, </div><div>+1 to "let's move TaskFlow vs Mistral" discussion to separate thread, </div><div>and my questions/comments on <a href="https://wiki.openstack.org/wiki/Mistral/Blueprints/ActionsDesign">https://wiki.openstack.org/wiki/Mistral/Blueprints/ActionsDesign</a> below: </div><div><br></div><div>- Async actions: how do results of async action communicates back? </div><div>My understanding it it assumes that the remote system will call back to mistral with action execution id, it's on the engine to call-back, and action needs to let the engine know to expect call-back. Let's put the explanation here. </div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- is_sync() - consider using an attribute instead - @mistral.async</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- can we think of a way to unify sync and async actions from engine's standpoint? So that we don't special-case it in the engine? <b>@ Joshua</b> - does something similar exists in TaskFlow already?</div><div><br></div><div>- def dry_run() - maybe name "test", let's stress that this method should return a representative sample output. </div><div><br></div><div>- Input - need a facility to declare, validate and list input parameters. Like VALID_KEYS=['url', 'parameters''] , def validate(): </div><div><br></div><div>- class HTTPAction(object):</div><div> def __init__(self, url, params, method, headers, body):</div><div>Not happy about declaring parameters explicitly. How about using * args **kvargs, or 'parameters' dictionary? </div><div><br></div><div>- DSL In-Place Declaration - I did minor edits in the section, please check. </div><div><br></div><div>DZ. </div><div>- <br><div><div>On Mar 12, 2014, at 6:54 PM, Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">So taskflow has tasks, which seems comparable to actions?<br><br>I guess I should get tired of asking but why recreate the same stuff ;)<br><br>The questions listed:<br><br>- Does action need to have revert() method along with run() method?<br>- How does action expose errors occurring during it's work?<br><br>- In what form does action return a result?<br><br><br>And more @ <a href="https://wiki.openstack.org/wiki/Mistral/Blueprints/ActionsDesign">https://wiki.openstack.org/wiki/Mistral/Blueprints/ActionsDesign</a><br><br>And quite a few others that haven't been mentioned (how does a action<br>retry? How does a action report partial progress? What's the<br>intertask/state persistence mechanism?) have been worked on by the<br>taskflow team for a while now...<br><br><a href="https://github.com/openstack/taskflow/blob/master/taskflow/task.py#L31">https://github.com/openstack/taskflow/blob/master/taskflow/task.py#L31</a><br>(and others...)<br><br>Anyways, I know mistral is still POC/pilot/prototype... but seems like<br>more duplicate worked that could just be avoided ;)<br><br>-Josh<br><br>-----Original Message-----<br>From: Renat Akhmerov <rakhmerov@mirantis.com><br>Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br><openstack-dev@lists.openstack.org><br>Date: Tuesday, March 11, 2014 at 11:32 PM<br>To: "OpenStack Development Mailing List (not for usage questions)"<br><openstack-dev@lists.openstack.org><br>Subject: [openstack-dev] [Mistral] Actions design BP<br><br><blockquote type="cite">Team,<br><br>I started summarizing all the thoughts and ideas that weąve been<br>discussing for a while regarding actions. The main driver for this work<br>is that the system keeps evolving and we still donąt have a comprehensive<br>understanding of that part. Additionally, we keep getting a lot of<br>requests and questions from our potential users which are related to<br>actions (Świll they be extensible?ą, Świll they have dry-run feature?ą,<br>Śwhat are the ways to configure and group them?ą and so on and so forth).<br>So although weąre still in a Pilot phase we need to start this work in<br>parallel. Even now lack of solid understanding of it creates a lot of<br>problems in pilot development.<br><br>I created a BP at launchpad [0] which has a reference to detailed<br>specification [1]. Itąs still in progress but you could already leave<br>your early feedback so that I donąt go in a wrong direction too far.<br><br>The highest priority now is still finishing the pilot so we shouldnąt<br>start implementing everything described in BP right now. However, some of<br>the things have to be adjusted asap (like Action interface and the main<br>implementation principles).<br><br>[0]: <br>https://blueprints.launchpad.net/mistral/+spec/mistral-actions-design<br>[1]: https://wiki.openstack.org/wiki/Mistral/Blueprints/ActionsDesign<br><br>Renat Akhmerov<br>@ Mirantis Inc.<br><br><br><br><br>_______________________________________________<br>OpenStack-dev mailing list<br>OpenStack-dev@lists.openstack.org<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote><br><br>_______________________________________________<br>OpenStack-dev mailing list<br>OpenStack-dev@lists.openstack.org<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></body></html>