<div dir="ltr">Hi Zane,<div><br></div><div>Thank you for your feedback. This is very important for us to find out how our approach can be aligned with existing solutions. Let me try to explain how we come up to specific solutions. </div>
<div><br></div><div><br></div><div>><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">It does seem really awkward to me (and not just because of all the $signs), because it's duplicating >basically all of the functionality of Heat. e.g. in MuranoPL you have:</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>Properties:</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>  name:</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>    Contract: $.string().notNull()</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>whereas in HOT this would be:</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>parameters:</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>  name:</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>    type: string</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>    constraints:</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>      - length: {min: 1}</span><br></div><div><br></div><div>First of all parameters are the common entities in all different services. Some of them use config files, some of them use yaml formats. I don't see that this is a significant overlap with Heat. While Murano parameters can be directly passed to Heat template generated, there is a major difference between Murano parameters and Heat parameters. We use these parameters to bind different entities together. The good example is here [1][2]</div>
<div><pre style="margin-top:0px;margin-bottom:0px"><div class="" id="LC14" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;padding-left:10px"><span class="" style>Properties</span><span class="" style>:</span></div>
<div class="" id="LC15" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;padding-left:10px">  <span class="" style>name</span><span class="" style>:</span></div>
<div class="" id="LC16" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;padding-left:10px">    <span class="" style>Contract</span><span class="" style>:</span> <span class="" style>$.string().notNull()</span></div>
<div class="" id="LC17" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;padding-left:10px"><br style></div><div class="" id="LC18" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;padding-left:10px">
  <span class="" style>primaryController</span><span class="" style>:</span></div><div class="" id="LC19" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;padding-left:10px">
    <span class="" style>Contract</span><span class="" style>:</span> <span class="" style>$.class(PrimaryController).notNull()</span></div><div class="" id="LC20" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;padding-left:10px">
<br style></div><div class="" id="LC21" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;padding-left:10px">  <span class="" style>secondaryControllers</span><span class="" style>:</span></div>
<div class="" id="LC22" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;padding-left:10px">    <span class="" style>Contract</span><span class="" style>:</span> <span class="" style>[</span><span class="" style="color:teal">$.class(SecondaryController).notNull()</span><span class="" style>]</span></div>
<div class="" id="LC22" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;padding-left:10px"><span class="" style><br></span></div>As you see, parameters here are used to bind different applications as PrimaryController and Secondary controllers are different VMs with different configurations. <br>
</pre><pre style="margin-top:0px;margin-bottom:0px">Murano can't use Heat parameters for that as we need to bind applications before Heat template is generated. If we even try to use Heat for keeping such parameters it will lead to Murano parsing and processing Heat templates which we want to avoid.  </pre>
<pre style="margin-top:0px;margin-bottom:0px"><br></pre><pre style="margin-top:0px;margin-bottom:0px">><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">Looking at e.g. [1], more  or less everything in here can be done already inside a Heat template, using get_f>ile and str_replace.</span></pre>
<pre style="margin-top:0px;margin-bottom:0px"><br></pre><pre style="margin-top:0px;margin-bottom:0px">This definitely can be done inside Heat template, but these operations (str_replace) are not specific to Heat. As we use these variables before HOT template creation it is better to do string operations inside the service then pass this to another service. As we can't expose python functions for that we just wrap them in our DSL syntax which is just a couple lines of Python code around pythons string methods.</pre>
<pre style="margin-top:0px;margin-bottom:0px"><br></pre></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>It sounds like this is a DSL in which you write everything imperatively, then it gets converted behind the >scenes into a declarative model in a completely different language (but not using any of the advanced >features of that language) and passed to Heat, which turns it back into a workflow to execute. That seems >bizarre to me. Surely Murano should be focusing on filling the gaps in Heat, rather than reimplementing it in >a different paradigm?</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">We will be very happy to fill gaps in the HOT syntax to extend it. At the same time, I need to mention, that the picture you drew does not perfectly reflects what we are doing. Murano uses its own definition of application which covers the specific aspects of application - actions and application binding. As a part of application definition we store Heat snippets as files. We don't hide anything from Heat under the Murano layer. All features available in Heat can be used in Murano as user has an ability to add Heat template to the application definition. As Heat main feature is to manage different resource we pass this tasks to Heat. Murano does not do any kind of infrastructure resource management outside of the Heat. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><font face="arial, sans-serif">Heat template generation is just a first step in Application life. Murano provides a way to define workflows for different aspects of application which can be invoked by Heat during generation or out of Heat by Mistral, Ceilometer and other services, including Murano.</font></div>
<div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>What I'm imagining here is something along the lines of:</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>- Heat implements hooks to customise its workflows, as proposed in [2], [3].</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>- Deployments are defined declaratively using HOT syntax.</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>- Workflows - to wrap the deployment operations, to customise the deployment and to perform lifecycle >operations like backups - are defined using a Mistral DSL (I assume this exists already? I haven't looked >into it).</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>- Murano provides a way to bundle the various workflow definitions, HOT models, and other files into an >application package.</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
</div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><font face="arial, sans-serif">Murano is not focused on deployment itself. As soon as we have HOT Murano is responsible to generate proper HOT template to make actual deployments. As soon as HOT Software components are ready, application publisher will use them in Heat templates. </font></div>
<div><br></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>Can anybody enlighten me as to what features would be missing from this that would warrant creating a >new programming language?</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><font face="arial, sans-serif">I see this in the following way - who will generate HOT template for my complex multi-tier applications when I have only templates for components? It looks like I will have to write a new template by myself understanding all possible relation between components and their parameters. Then I have to add some specific workflows to Mistral and somehow bind them to the resources deployed by Heat. Then I have to understand what kind of notifications to expect and somehow react on them or configure Mistral to call some workflows. I think this was a motivation for a new language which will reflect these specifics of applications and their bindings. Currently Murano workflows are processed by Murano engine, but I expect to see in the future, when Mistral is mature enough, Murano will just add corresponding workflows as Mistral entities and will use it to do workflows execution. </font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I hope I cleared some of your questions. I don't say that Murano DSL is the only solution. I probably miss something as it is not possible to know everything. I will be glad to continue this discussion and find out the right way of doing the tasks we are doing now in Murano.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><br></div><div><font face="arial, sans-serif"><br></font></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div>
[1] - <a href="https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.services.windows.failoverCluster.FailoverCluster/manifest.yaml">https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.services.windows.failoverCluster.FailoverCluster/manifest.yaml</a></div>
<div>[2] - <a href="https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.services.windows.activeDirectory.ActiveDirectory/manifest.yaml">https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.services.windows.activeDirectory.ActiveDirectory/manifest.yaml</a></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 10:35 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(I added a couple of tags to the subject; hope this doesn't screw up anyone's threading.)<div class=""><br>
<br>
On 09/03/14 16:26, Joshua Harlow wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd be very interested in knowing the resource controls u plan to add.<br>
Memory, CPU...<br>
<br>
I'm still trying to figure out where something like<br>
<a href="https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.demoApp.DemoInstance/manifest.yaml" target="_blank">https://github.com/istalker2/<u></u>MuranoDsl/blob/master/meta/<u></u>com.mirantis.murano.demoApp.<u></u>DemoInstance/manifest.yaml</a><br>

would be beneficial, why not just spend effort sand boxing lua,<br>
python... Instead of spending effort on creating a new language and then<br>
having to sandbox it as well... Especially if u picked languages that<br>
are made to be sandboxed from the start (not python)...<br>
</blockquote>
<br></div>
-1 to using a full-blown programming language like Python over a DSL, but...<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Who is going to train people on muranoPL, write language books and<br>
tutorials when the same amount of work has already been done for 10+<br>
years for other languages....<br>
<br>
I fail to see where muranoPL is a DSL when it contains a full language<br>
already with functions, objects, namespaces, conditionals... (what is<br>
the domain of it?), maybe I'm just confused though (quite possible, haha).<br>
</blockquote>
<br></div>
...I'm inclined to agree with this. Whenever you find yourself implementing a Turing-complete Object-Oriented DSL... well, you'd at least want to stop and think very carefully about whether you might have taken a wrong turn somewhere.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does this not seem awkward to anyone else??<br>
</blockquote>
<br></div>
It does seem really awkward to me (and not just because of all the $signs), because it's duplicating basically all of the functionality of Heat. e.g. in MuranoPL you have:<br>
<br>
Properties:<br>
  name:<br>
    Contract: $.string().notNull()<br>
<br>
whereas in HOT this would be:<br>
<br>
parameters:<br>
  name:<br>
    type: string<br>
    constraints:<br>
      - length: {min: 1}<br>
<br>
In MuranoPL you reference it using "$<a href="http://this.name" target="_blank">this.name</a>", vs. HOT using "{get_param: name}".<br>
<br>
Note that HOT (a) already exists in OpenStack, and (b) is being developed in conjunction with TOSCA folks to ensure easy translation to/from TOSCA Simple Profile YAML rendering.<br>
<br>
Looking at e.g. [1], more  or less everything in here can be done already inside a Heat template, using get_file and str_replace.<br>
<br>
It sounds like this is a DSL in which you write everything imperatively, then it gets converted behind the scenes into a declarative model in a completely different language (but not using any of the advanced features of that language) and passed to Heat, which turns it back into a workflow to execute. That seems bizarre to me. Surely Murano should be focusing on filling the gaps in Heat, rather than reimplementing it in a different paradigm?<br>

<br>
What I'm imagining here is something along the lines of:<br>
- Heat implements hooks to customise its workflows, as proposed in [2], [3].<br>
- Deployments are defined declaratively using HOT syntax.<br>
- Workflows - to wrap the deployment operations, to customise the deployment and to perform lifecycle operations like backups - are defined using a Mistral DSL (I assume this exists already? I haven't looked into it).<br>

- Murano provides a way to bundle the various workflow definitions, HOT models, and other files into an application package.<br>
<br>
Can anybody enlighten me as to what features would be missing from this that would warrant creating a new programming language?<br>
<br>
thanks,<br>
Zane.<br>
<br>
[1] <a href="https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.demoApp.DemoInstance/manifest.yaml" target="_blank">https://github.com/istalker2/<u></u>MuranoDsl/blob/master/meta/<u></u>com.mirantis.murano.demoApp.<u></u>DemoInstance/manifest.yaml</a><br>

[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-February/026329.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2014-<u></u>February/026329.html</a><br>
[3] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-March/030228.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2014-<u></u>March/030228.html</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
Sent from my really tiny device...<br>
<br>
On Mar 8, 2014, at 10:44 PM, "Stan Lagun" <<a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a><br></div>
<mailto:<a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a>>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
First of all MuranoPL is not a host but hosted language. It never<br>
intended to replace Python and if Python can do the job it is probably<br>
better than MuranoPL for that job.<br>
The problem with Python is that you cannot have Python code as a part<br>
of your DSL if you need to evaluate that DSL on server-side. Using<br>
Python's eval() is not secure. And you don't have enough control on<br>
what evaled code is allowed to do. MuranoPL on the contrary are fully<br>
sandboxed. You have absolute control over what functions/methods/APIs<br>
are exposed to DSL and DSL code can do nothing except for what it<br>
allowed to do. Besides you typically do want your DSL to be<br>
domain-specific so general-purpose language like Python can be suboptimal.<br>
<br>
I don't say MuranoPL is good for all projects. It has many<br>
Murano-specific things after all. In most cases you don't need all<br>
those OOP features that MuranoPL has. But the code organization, how<br>
it uses YAML, block structures and especially YAQL expressions can be<br>
of a great value to many projects<br>
<br>
For examples of MuranoPL classes you can browse<br>
<a href="https://github.com/istalker2/MuranoDsl/tree/master/meta" target="_blank">https://github.com/istalker2/<u></u>MuranoDsl/tree/master/meta</a> folder. This<br>
is my private repository that I was using to develop PoC for MuranoPL<br>
engine. We are on the way to create production-quality implementation<br>
with unit-tests etc. in regular Murano repositories on stackforge<br>
<br>
<br>
On Sun, Mar 9, 2014 at 7:33 AM, Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com" target="_blank">harlowja@yahoo-inc.com</a><br></div><div class="">
<mailto:<a href="mailto:harlowja@yahoo-inc.com" target="_blank">harlowja@yahoo-inc.com</a><u></u>>> wrote:<br>
<br>
    To continue from other thread....<br>
<br>
    """<br>
    Personally I believe that YAQL-based DSLs similar (but probably<br>
    simlet than) MuranoPL can be of a great value for many OpenStack<br>
    projects that have DSLs of different kind. Murano for App<br>
    Catatalog, Mistral for workflows, Heat for HOT templates,<br>
    Ceilometer for alarms & counter aggregation rules, Nova for<br>
    customizable resource scheduling and probably many more.<br>
    """<br>
<br>
    Isn't python a better host language for said DSLs than muranoPL? I<br>
    am still pretty weary of a DSL that starts to grow so many<br>
    features to encompass other DSLs since then it's not really a DSL<br>
    but a non-DSL, and we already have one that everyone is familiar<br>
    with (python).<br>
<br>
    Are there any good examples if muranoPL that I can look at that<br>
    take advantage of muranoPL classes, functions, namespaces which<br>
    can be compared to there python equivalents. Has such an<br>
    analysis/evaluation been done?<br>
<br>
    Sent from my really tiny device...<br>
    ______________________________<u></u>_________________<br>
    OpenStack-dev mailing list<br>
    <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br></div>
    <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><div class=""><br>
    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
<br>
<br>
<br>
--<br>
Sincerely yours<br>
Stanislav (Stan) Lagun<br>
Senior Developer<br>
Mirantis<br>
35b/3, Vorontsovskaya St.<br>
Moscow, Russia<br>
Skype: stanlagun<br>
</div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a> <<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com/</a>><br>
<a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a> <mailto:<a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a>><div class=""><br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br></div>
<mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote><div class="">
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div>
</div>