<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi all,<br><br></div>Completely agree with Zane. Collaboration with TOSCA TC is a way to go as Murano is very close to TOSCA. Like Murano = 0.9 * TOSCA + UI + OpenStack services integration.<br>

<br></div>Let me share my thoughts on TOSCA as I read all TOSCA docs and I'm also the author of initial Murano DSL design proposal so I can probably compare them.<br><br></div>We initially considered to just implement TOSCA before going with own DSL. There was no YAML TOSCA out there at that time, just XML version.<br>

<br></div>So here's why we've wrote our own DSL:<br><br></div>1. TOSCA is very complex and verbose. Considering there is no production-ready tooling for TOSCA users would have to type all those tons of XML tags and namespaces and TOSCA XMLs are really hard to read and write. No one gonna do this, especially outside of Java-enterprise world<br>

<br></div>2. TOSCA has no workflow language. TOSCA draft states that the language is indeed needed and recommends using BPEL or BPMN for that matter. <br></div>Earlier versions of Murano showed that some sort of workflow language (declarative, imperative whatever) if absolutely required for non-trivial cases. If you don't have workflow language then you have to hard-code a lot of knowledge into engine in Python. But the whole idea of AppCatalog was that users upload (share) their application templates that contain application-specific maintenance/deployment code that is run in on common shared server (not in any particular VM) and thus capable of orchestrating all activities that are taking place on different VMs belonging to given application (for complex applications with typical enterprise SOA architecture). Besides VMs applications can talk to OpenStack services like Heat, Neutron, Trove and 3rd party services (DNS registration, NNTP, license activation service etc). Especially with the Heat so that application can have its VMs and other IaaS resources. There is a similar problem in Heat - you can express most of the basic things in HOT but once you need something really complex like accessing external API, custom load balancing or anything tricky you need to resort to Python and write custom resource plugin. And then you required to have root access to engine to install that plugin. This is not a solution for Murano as in Murano any user can upload application manifest at any time without affecting running system and without admin permissions.<br>

<br></div>Now going back to TOSCA the problem with TOSCA workflows is they are not part of standard. There is no standardized way how BPEL would access TOSCA attributes and how 2 systems need to interact. This alone makes any 2 TOSCA implementations incompatible with each other rendering the whole idea of standard useless. It is not standard if there is no compatibility.<br>

<br></div>And again BPEL is heavy XML language that you don't want to have in OpenStack. Trust me, I spent significant time studying it. And if there is YAML version of TOSCA that is much more readable than XML one there is no such thing for BPEL. And I'm not aware of any adequate replacement for it<br>

<br></div>3. It seems like nobody really using TOSCA. TOSCA standard defines exact TOSCA package format. TOSCA was designed so that people can share those packages (CSARs as TOSCA calls them) between various TOSCA implementations. I've tried to google those packages. It took me like a hour to find even most trivial CSAR example. And it was on OASIS site.<br>

<br></div>4. There is no reference TOSCA implementation. No test suite. There is no way to check your implementation is really TOSCA-compatible. And no one to ask questions<br><br></div>5. TOSCA is very immature. They didn't even made XML version used and already working on YAML version that is not compatible with current draft<br>

 <br></div>6. TOSCA is too restrictive and verbose in some areas while leaving a lot of white spaces in others<br><br><br></div>So we decided to go with our own DSL that would eliminate all the problems above. And I personally feel that Murano is how TOSCA should be looked like if it was designed for OpenStack. Murano is perfectly aligned with Heat and other OpenStack services and practices. It is very Python-like. It is easy to read and write once you learn the basics. It is more universal and less restrictive than TOSCA. You can do much more than you could ever do in TOSCA. And it is very extensible. <br>

<br></div>I hope that Murano and its ideas will find a way into OpenStack community :)<br><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><br></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 Wed, Mar 5, 2014 at 2:16 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"><div class="">On 04/03/14 00:04, Georgy Okrokvertskhov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
First of all let me highlight that Murano DSL was much inspired by<br>
TOSCA. We carefully read this standard before our movement to Murano<br>
DSL. TOSCA standard has a lot f of very well designed concepts and ideas<br>
which we reused in Murano. There is one obvious draw back of TOSCA -<br>
very heavy and verbose XML based syntax. Taking into account that<br>
OpenStack itself is clearly moving from XML based representations, it<br>
will be strange to bring this huge XML monster back on a higher level.<br>
Frankly, the current Murano workflows language is XML based and it is<br>
quite painful to write a workflows without any additional instrument<br>
like IDE.<br>
</blockquote>
<br></div>
It so happens that the OASIS's TOSCA technical committee are working as we speak on a "TOSCA Simple Profile" that will hopefully make things easier to use and includes a YAML representation (the latter is great IMHO, but the key to being able to do it is the former). Work is still at a relatively early stage and in my experience they are very much open to input from implementers.<br>


<br>
I would strongly encourage you to get involved in this effort (by joining the TOSCA TC), and also to architect Murano in such a way that it can accept input in multiple formats (this is something we are making good progress toward in Heat). Ideally the DSL format for Murano+Heat should be a trivial translation away from the relevant parts of the YAML representation of TOSCA Simple Profile.<div class="HOEnZb">

<div class="h5"><br>
<br>
cheers,<br>
Zane.<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"><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>