<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>This may be not proper thread to discuss MuranoPL but since I suggested Mistral to borrow some parts of it let me answer it here. <br>

<br></div>Q: Why not use some existing language?<br></div><br>A:<br></div> 1. There are not so many languages that can be embedded and securely used to run code in shared environments. And it cannot be Python itself (unless you're Google :) ). So anyway most of Murano audience would have to learn new language (cause they typically use Python ans shell for their job and we cannot use neither of them)<br>

<br></div> 2. MuranoPL is DSL - Domain Specific Language, not General-Purpose language. The specific part about MuranoPL is object composition. Let me explain.<br></div>In regular languages like Python you control entire application composition: it is your program who instantiates objects and assign those objects to attributes of other objects. You know (typically from documentation) what object type/value is expected to be in particular attribute/method argument. It is you who decide which 3rd party libraries to use in your project and map your requests to their APIs. You can validate your input/attributes/parameters anytime and most of the time you don't even need to to this as it is you who who is the caller and you trust your code. Besides you can rely on your unit-tests.<br>

<br></div>This is all what Murano is not. In Murano AppCatalog is a (hopefully) huge collection of classes that are written by different people (no central app that glue everything). It is end user that does object composition (binds objects together) and sets their attributes in UI dashboard. MuranoPL code is not instantly running and thus has no control over what is done in dashboard. Thats why MuranoPL has contracts that are much stricter than Java's statical typing. With contracts you validate even the most complex data structures, value types and constraints. Contracts is how you know that one object expects another instance of particular type. That allows constructing valid object model in UI without DSL code execution for every single UI click. That allows dynamic construction of UI forms - you know in advance what type value is expected for each attribute and how to validate it.<br>

</div>This is just one (but not the only) example of domain-specific feature that you will not have in lua or JavaScript. Mistral would probably have other unique domain-specific features.<br><br></div> 3. In MuranoPL everything can be customized. You control list of global/built-in f unctions and can have your own customized versions of them. You can have your domain-specific operators in expressions or modify standard ones (you can even make 2+2=5). You control all the program APIs so that no I/O is possible except for explicitly provided to DSL. You control the heap: you can hibernate the entire program at any time and resume it on another server from that place. You can have your own block constructs. You would not have such level of control with any other language<br>

<br></div> 4. Domain-specific is usually better than general-purposed<br><br></div><br>Q: Why YAML?<br></div><br>A: <br></div> 1. There are 2 possible alternatives: use some existing data format (XML, JSON, YAML) or create your own. And your own format for your own language means your own parser. And writing a parser for language of that complexity is a difficult task that would take months of work. From standard formats YAML is clearly most readable one<br>

</div><br> 2. There are a lot of XML languages. There is BPEL XML language for workflows. So there is nothing unusual in having programming language encoded as data serialization format. So why not have YAML for the same purpose considering it is more readable than XML?<br>

<br></div> 3. MuranoPL is not only code but also declarations - classes, properties, inheritance, methods, contracts etc. YAML is really good for declarations<br><br></div> 4. As for the code there is not so many difference from having you own parser. Sure you need to prepend dash (-) before each code line, but in Java/C you append semicolon after each like and everyone okay with that. In Python you write var = value, in MuranoPL $var: value. You use colon for block constructs in Python and in MuranoPL. As you can see there are not so many differences from normal Python code as one can expect from not using custom parser. As soon as you start writing in MuranoPL you soon forget that this is YAML and treat it like a normal language.<br>

<br></div><div>5. Because of YAML all JSON/YAML data structures that looks so nice and readable in YAML become first class citizens in MuranoPL. You can easily embed Heat template of REST API JSON body in DSL code. This even better than in Python<br>

<br></div><div>6. Everyone can take MuranoPL class and see what properties it exposes, what methods it has as all you need is standard YAML parser<br><br></div><div>7. YAML is still a data serialization format. So you can work with DSL code as with regular data - store in data base, insert code lines and methods, convert to other formats etc.<br>

<br></div><div>8. You can customize many thing on YAML parser level before it reaches DSL. DSL does not deal directly with YAML, only deserialized version of it. Thus you can control where those YAMLs are located. You can store them in Glance, database, file-system or generate them on the fly without DSL even notice.<br>

<br></div><div>9. With YAML you has less to explain (people already know it) and more of a tooling and IDE support<br><br></div><div><br>Q: Isn't DSL of that power would be a subject to DoS attacks, resource starvation attacks etc.?<br>

<br></div><div>A: This is a really good question cause nobody asked it yet :) And the answer is NO. Here is why:<br><br></div><div>With MuranoPL you have complete control over everything. You can have time quota for DSL code (remember 30 second quota for PHP scrips in typical web setup?). Or you can limit DSL scripts to some reasonable number of executed instructions. Or count raw CPU time for the script. You can make all loop constructs to have upper limit on iterations. You can do the same with YAQL functions.  You can enforce timeouts on all I/O operations. MuranoPL uses green threads and you can have a lot of them (unlike regular threads) and it is possible to limit total number of green threads used for DSL execution. It is possible to even limit memory usage. DSL code cannot allocate operating-system-level resources like file handles of TCP sockets. And there is garbage collector as DSL in interpreted on top of Python.<br>

</div><div><br>How easy it would be to do the same with JavaScript/Lua/whatever?<br></div><div><br></div><br></div><br></div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><br><br></div>

</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 8, 2014 at 7:05 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@yahoo-inc.com" target="_blank">harlowja@yahoo-inc.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>What are the benefits of MuranoPL over a already established language?</div>
<div><br>
</div>
<div>I noted the following and don't quite understand why they are needed (reinventing a language):</div>
<div><br>
</div>
<div>
<div>- <a href="https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Extends" target="_blank">https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Extends</a></div>
<div>- <a href="https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Block_constructs" target="_blank">https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Block_constructs</a></div>
<div>Q: where are those looping constructs executed? How hard is it to DOS murano servers (submitting jobs that loop forever). What execution limits are imposed? I noted that the parallel construct actually exposes the number of green threads (isn't this an
 avenue for resource starvation?).</div>
<div>- <a href="https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Object_model" target="_blank">https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Object_model</a></div>
</div>
<div><br>
</div>
<div>IMHO, something just doesn't seem right when the above is created, fitting a language into YAML seems about as awkward as creating a language in XML (xquery[1] for example) . Why was this really preferred over just python or something simpler for example,
 [lua, javascript…], that already has language/object constructs… built-in and have runtimes that u can control the security domain of (python is not a good choice to run arbitrary code-in, find out how much energy google put into python + app-engine and u'll
 see what it takes).</div>
<div><br>
</div>
<div><a href="http://en.wikipedia.org/wiki/XQuery#Examples" target="_blank">http://en.wikipedia.org/wiki/XQuery#Examples</a></div>
<div><br>
</div>
<span>
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">


<span style="font-weight:bold">From: </span>Stan Lagun <<a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a>><div class=""><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>


</div><span style="font-weight:bold">Date: </span>Friday, March 7, 2014 at 9:36 AM<div class=""><br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>


<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Mistral] Crack at a "Real life" workflow<br>
</div></div><div><div class="h5">
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hello everyone!<br>
<br>
</div>
Actually it is possible to construct YAML-based DSL that has all the constructs of regular OOP language like Python and at the same time be safe enough to be used for execution of untrusted code on shared server.<br>
<br>
</div>
Take a look at Murano DSL.<br>
</div>
For example the code above defines class "Instance": <a href="https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.services.Instance/manifest.yaml" target="_blank">
https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.services.Instance/manifest.yaml</a></div>
The part that may be useful for Mistral is under Workflow key.<br>
</div>
Here is some doc on the language: <a href="https://wiki.openstack.org/wiki/Murano/DSL/Blueprint" target="_blank">
https://wiki.openstack.org/wiki/Murano/DSL/Blueprint</a><br>
<div>
<div>
<div>
<div>
<div>Technically you can code any workflow that you can in Python using such language (just don't look at all OOP-related stuff) and it will look very similar to Python but be safe as you can only call APIs that are explicitly provided for DSL<br>


<br>
</div>
<div>Hope this might be helpful for Mistral<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Mar 7, 2014 at 10:38 AM, Dmitri Zimine <span dir="ltr">
<<a href="mailto:dz@stackstorm.com" target="_blank">dz@stackstorm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">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" target="_blank">https://github.com/dzimine/mistral-workflows/commit/d8c4a8c845e9ca49f6ea94362cef60489f2a46a3</a><span><font color="#888888"><br>


</font></span>
<div><span><font color="#888888">
<div><br>
</div>
<div>DZ> </div>
</font></span>
<div>
<div>
<div><br>
<div>
<div>On Mar 6, 2014, at 10:36 PM, Dmitri Zimine <<a href="mailto:dz@stackstorm.com" target="_blank">dz@stackstorm.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div style="word-wrap:break-word">
<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" target="_blank">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" target="_blank">sandy.walsh@rackspace.com</a>> wrote:</div>
<br>
<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" target="_blank">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" target="_blank">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" target="_blank">
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" target="_blank">https://gist.github.com/dzimine/9380941</a><br>
or here <a href="http://paste.openstack.org/show/72741/" target="_blank">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" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">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" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">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" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">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" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">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" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">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>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div dir="ltr"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:'Times New Roman';word-spacing:0px"><span style="font-family:arial;font-size:small">Sincerely
 yours<br>
Stanislav (Stan) Lagun<br>
Senior Developer<br>
Mirantis</span></span><br>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:'Times New Roman';word-spacing:0px"><span style="font-family:arial;font-size:small"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">35b/3, Vorontsovskaya
 St.</span><br>
Moscow, Russia<br>
Skype: stanlagun<br>
<a href="http://www.mirantis.com/" target="_blank">www.mirantis.com</a><br>
<a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a></span></span></div>
</div>
</div>
</div>
</blockquote>
</div></div></span>
</div>

</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours<br>

Stanislav (Stan) Lagun<br>Senior Developer<br>Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"" lang="EN-US">35b/3, Vorontsovskaya
St.</span><br>Moscow, Russia<br>Skype: stanlagun<br><a href="http://www.mirantis.com/" target="_blank">www.mirantis.com</a><br><a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a></span></span></div>


</div>