<div dir="ltr">Hi Zane,<div><br></div><div>Thank you very much for this question.</div><div><br></div><div>First of all let me highlight that Murano DSL was much inspired by TOSCA. We carefully read this standard before our movement to Murano DSL. TOSCA standard has a lot f of very well designed concepts and ideas which we reused in Murano. There is one obvious draw back of TOSCA - very heavy and verbose XML based syntax. Taking into account that OpenStack itself is clearly moving from XML based representations, it will be strange to bring this huge XML monster back on a higher level. Frankly, the current Murano workflows language is XML based and it is quite painful to write a workflows without any additional instrument like IDE. </div>
<div><br></div><div>Now let me remind that TOSCA has a defined scope of its responsibility. There is a list of areas which are out of scope. For Murano it was important to see that the following items are out of TOSCA scope:</div>
<div>Citations from [1]:</div><div>...</div><div>2. <span style="color:rgb(0,0,0);font-family:Verdana,Tahoma,'DejaVu Sans',sans-serif;font-size:12px;line-height:18px">The definition of concrete plans, i.e. the definition of plans in any process modeling language like BPMN or BPEL.</span></div>
<div><span style="color:rgb(0,0,0);font-family:Verdana,Tahoma,'DejaVu Sans',sans-serif;font-size:12px;line-height:18px">3. The definition of a language for defining plans (i.e. a new process modeling language).</span></div>
<div>...</div><div>Plans in TOSCA understanding is something similar to workflows. This is what we address by Murano workflow.</div><div><br></div><div>Not let me go through TOSCA ideas and show how they are reflected in Murano. It will be a long peace of text so feel free to skip it.</div>
<div><br></div><div>Taking this into account lets review what we have in Murano as an application package. Inside application package we have:</div><div>1. Application metadata which describes application, its relations and properties</div>
<div>2. Heat templates snippets</div><div>3. Scripts for deployment</div><div>4. Workflow definitions</div><div><br></div><div>In TOSCA document in section 3.2.1 there are Service Templates introduced. These templates are declarative descriptions of services components and service Topologies. Service templates can be stored in catalog to be found and used by users. This  service template description is abstracted from actual infrastructure implementation and each cloud provider maps this definition to actual cloud infrastructure. This is definitely a part which is already covered by Heat.  </div>
<div>The same section says the following:  "<span style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:13.63636302947998px">Making a concrete instance of a Topology Template can be done by running a corresponding Plan (so-called instantiating management plan, a.k.a. build plan). This build plan could be provided by the service developer who also creates the Service Template." </span>This plan part which is out of scope of TOSCA is essentially what Murano adds as a part of application definition.</div>
<div><br></div><div>Section 3.3 of TOSCA document introduces an new entity - artifacts. Artifact is a name for content which is needed for service deployment including (scripts, executables, binaries and images). That is why Murano has a metadata service to store artifacts as a part of application package. Moreover, Murano works with Glance team to move this metadata repository from Murano to Glance providing generic artifact repository which can be used not only by Murano but by any other services.</div>
<div><br></div><div>Sections 3.4 and 3.5 explain the idea of Relationships with Compatibilities and Service Composition. Murano actually implements all these high level features. Application definition has a section with contract definitions. This contract syntax is not just a declaration of the relations and capabilities but also a way to make assertions and on-the fly type validation and conversion if needed.  Section 10 reveals details of requirements. It explains that requirements can be complex: inherit each other and be abstract to define a broad set of required values. Like when service requires relation database it will require type=RDMS without assuming the actual DB implementation MySQL, PostgreSQL or MSSQL. </div>
<div><br></div><div>In order to solve the problem of complex requirements, relations and service composition we introduced  classes in our DSL. It was presented and discussed in this e-mail thread [3]. Murano DSL syntax allows application package writer to compose applications from existing classes by using inheritance and class properties with complex types like classes. It is possible to define a requirement with using abstract classes to define specific types of applications and services like databases, webservers and other. Using class inheritance Murano will be able to satisfy the requirement by specific object which proper parent class by checking the whole hierarchy of objects parent classes which can be abstract.</div>
<div><br></div><div>I don't want to cover all entities defined in TOSCA as most important were discussed already. There are implementations of many TOSCA concepts in Murano, like class properties for TOSCA Properties, class methods for TOSCA Operations etc.</div>
<div><br></div><div>TL;DR</div><div><br></div><div>Summarizing everything I wrote above, I can say that Murano is a lightweight implementation of TOSCA ideas without XML syntax and declarative parts which are covered by Heat. This is definitely not an implementation of TOSCA standard as is, but I am not sure that this is event necessary. If TOSCA standard will be a requirement it can be done with Murano engine as it has all necessary concepts and this is a question of translation between different syntax. There are probably some parts still missed, but we use pragmatic approach by introducing new concepts and ideas when it is necessary.</div>
<div><br></div><div>Zane, thanks again for this question. I think my explanation of Murano and TOSCA relations will help to understand what value Murano adds for OpenStack. In this e-mail we actually discussed only one Murano component which is responsible for application package processing. I did not touch the Application Catalog part as this is not a part of TOSCA standard.</div>
<div><br></div><div><br></div><div><br></div><div>[1] - TOSCA TC Scope of work:  <a href="https://www.oasis-open.org/committees/tosca/charter.php">https://www.oasis-open.org/committees/tosca/charter.php</a></div><div>[2] -  TOSCA standard document:  <a href="http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html">http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html</a> </div>
<div>[3] - DSL discussion e-mail thread:  <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-February/027938.html">http://lists.openstack.org/pipermail/openstack-dev/2014-February/027938.html</a> </div><div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 3, 2014 at 6:33 PM, 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"><div class="">On 25/02/14 05:08, Thierry Carrez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The second challenge is that we only started to explore the space of<br>
workload lifecycle management, with what looks like slightly overlapping<br>
solutions (Heat, Murano, Solum, and the openstack-compatible PaaS<br>
options out there), and it might be difficult, or too early, to pick a<br>
winning complementary set.<br>
</blockquote>
<br></div>
I'd also like to add that there is already a codified OASIS standard (TOSCA) that covers application definition at what appears to be a similar level to Murano. Basically it's a more abstract version of what Heat does plus workflows for various parts of the lifecycle (e.g. backup).<br>

<br>
Heat and TOSCA folks have been working together since around the time of the Havana design summit with the aim of eventually getting a solution for launching TOSCA applications on OpenStack. Nothing is set in stone yet, but I would like to hear from the Murano folks how they are factoring compatibility with existing standards into their plans.<br>

<br>
cheers,<br>
Zane.<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>