<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; ">I just moved the sample to Git; let's leverage git review for specific comments on the syntax. <div><br></div><div><a href="https://github.com/dzimine/mistral-workflows/commit/d8c4a8c845e9ca49f6ea94362cef60489f2a46a3">https://github.com/dzimine/mistral-workflows/commit/d8c4a8c845e9ca49f6ea94362cef60489f2a46a3</a><br><div><div><br></div><div>DZ> </div><div><br><div><div>On Mar 6, 2014, at 10:36 PM, Dmitri Zimine <<a href="mailto:dz@stackstorm.com">dz@stackstorm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Folks, thanks for the input! </div><div><br></div>@Joe: <div><br></div><div>Hopefully Renat covered the differences. Yet I am interested in how the same workflow can be expressed as Salt state(s) or Ansible playbooks. Can you (or someone else who knows them well) take a stub? <div><br></div><div><br></div><div><div>@Joshua</div><div>I am still new to Mistral and learning, but I think it _is_ relevant to taskflow. Should we meet, and you help me catch up? Thanks! </div></div><div><br></div><div>@Sandy:</div><div>Aaahr, I used the "D" word?! :) I keep on arguing that YAML workflow representation doesn't make DSL. </div><div><br></div><div>And YES to the object model first to define the workflow, with YAML/JSON/PythonDSL/what-else as a syntax to build it. We are having these discussions on another thread and reviews. </div><div><br></div><div><blockquote type="cite">Basically, in order to make a grammar expressive enough to work across a<br>web interface, we essentially end up writing a crappy language. Instead,<br>we should focus on the callback hooks to something higher level to deal<br>with these issues. Minstral should just say "I'm done this task, what<br>should I do next?" and the callback service can make decisions on where<br>in the graph to go next.</blockquote><br></div><div>There must be some misunderstanding. Mistral _does follow AWS / BPEL engines approach, it is both doing "I'm done this task, what should I do next?" (executor) and "callback service" (engine that coordinates the flow and keeps the state). Like decider and activity workers in AWS Simple Workflow.</div><div><br></div><div>Engine maintains the state. Executors run tasks. Object model describes workflow as a graph of tasks with transitions, conditions, etc. YAML is one way to define a workflow. Nothing controversial :) </div><div><br></div><div><div>@all:</div><div><br></div><div><div>Wether one writes Python code or uses yaml? Depends on the user. There are good arguments for YAML. But if it's crappy, it looses. We want to see how it feels to write it. To me, mixed feelings so far, but promising. What do you guys think?</div><div><br></div><div>Comments welcome here: </div><div><a href="https://github.com/dzimine/mistral-workflows/commit/d8c4a8c845e9ca49f6ea94362cef60489f2a46a3">https://github.com/dzimine/mistral-workflows/commit/d8c4a8c845e9ca49f6ea94362cef60489f2a46a3</a></div><div><br></div><div><br></div><div><div></div></div></div><div>DZ> </div><div><br></div><div><br><div><div>On Mar 6, 2014, at 10:41 AM, Sandy Walsh <<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br>On 03/06/2014 02:16 PM, Renat Akhmerov wrote:<br><blockquote type="cite">IMO, it looks not bad (sorry, I’m biased too) even now. Keep in mind this is not the final version, we keep making it more expressive and concise.<br><br>As for killer object model it’s not 100% clear what you mean. As always, devil in the details. This is a web service with all the consequences. I assume what you call “object model” here is nothing else but a python binding for the web service which we’re also working on. Custom python logic you mentioned will also be possible to easily integrate. Like I said, it’s still a pilot stage of the project.<br></blockquote><br>Yeah, the REST aspect is where the "tricky" part comes in :)<br><br>Basically, in order to make a grammar expressive enough to work across a<br>web interface, we essentially end up writing a crappy language. Instead,<br>we should focus on the callback hooks to something higher level to deal<br>with these issues. Minstral should just say "I'm done this task, what<br>should I do next?" and the callback service can make decisions on where<br>in the graph to go next.<br><br>Likewise with things like sending emails from the backend. Minstral<br>should just call a webhook and let the receiver deal with "active<br>states" as they choose.<br><br>Which is why modelling this stuff in code is usually always better and<br>why I'd lean towards the TaskFlow approach to the problem. They're<br>tackling this from a library perspective first and then (possibly)<br>turning it into a service. Just seems like a better fit. It's also the<br>approach taken by Amazon Simple Workflow and many BPEL engines.<br><br>-S<br><br><br><blockquote type="cite">Renat Akhmerov<br>@ Mirantis Inc.<br><br><br><br>On 06 Mar 2014, at 22:26, Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>> wrote:<br><br><blockquote type="cite">That sounds a little similar to what taskflow is trying to do (I am of course biased).<br><br>I agree with letting the native language implement the basics (expressions, assignment...) and then building the "domain" ontop of that. Just seems more natural IMHO, and is similar to what linq (in c#) has done.<br><br>My 3 cents.<br><br>Sent from my really tiny device...<br><br><blockquote type="cite">On Mar 6, 2014, at 5:33 AM, "Sandy Walsh" <<a href="mailto:sandy.walsh@RACKSPACE.COM">sandy.walsh@RACKSPACE.COM</a>> wrote:<br><br>DSL's are tricky beasts. On one hand I like giving a tool to<br>non-developers so they can do their jobs, but I always cringe when the<br>DSL reinvents the wheel for basic stuff (compound assignment<br>expressions, conditionals, etc).<br><br>YAML isn't really a DSL per se, in the sense that it has no language<br>constructs. As compared to a Ruby-based DSL (for example) where you<br>still have Ruby under the hood for the basic stuff and extensions to the<br>language for the domain-specific stuff.<br><br>Honestly, I'd like to see a killer object model for defining these<br>workflows as a first step. What would a python-based equivalent of that<br>real-world workflow look like? Then we can ask ourselves, does the DSL<br>make this better or worse? Would we need to expose things like email<br>handlers, or leave that to the general python libraries?<br><br>$0.02<br><br>-S<br><br><br><br><blockquote type="cite">On 03/05/2014 10:50 PM, Dmitri Zimine wrote:<br>Folks, <br><br>I took a crack at using our DSL to build a real-world workflow. <br>Just to see how it feels to write it. And how it compares with<br>alternative tools. <br><br>This one automates a page from OpenStack operation<br>guide: <a href="http://docs.openstack.org/trunk/openstack-ops/content/maintenance.html#planned_maintenance_compute_node">http://docs.openstack.org/trunk/openstack-ops/content/maintenance.html#planned_maintenance_compute_node</a> <br><br>Here it is <a href="https://gist.github.com/dzimine/9380941">https://gist.github.com/dzimine/9380941</a><br>or here <a href="http://paste.openstack.org/show/72741/">http://paste.openstack.org/show/72741/</a><br><br>I have a bunch of comments, implicit assumptions, and questions which<br>came to mind while writing it. Want your and other people's opinions on it. <br><br>But gist and paste don't let annotate lines!!! :(<br><br>May be we can put it on the review board, even with no intention to<br>check in, to use for discussion? <br><br>Any interest?<br><br>DZ> <br><br><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></blockquote><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></blockquote><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></blockquote><br><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br><br></blockquote><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div></div></body></html>