Open Stack

Hi all,

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.

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.

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.

So here's why we've wrote our own DSL:

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

2. TOSCA has no workflow language. TOSCA draft states that the language is
indeed needed and recommends using BPEL or BPMN for that matter.
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.

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.

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

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.

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

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

6. TOSCA is too restrictive and verbose in some areas while leaving a lot
of white spaces in others


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.

I hope that Murano and its ideas will find a way into OpenStack community :)



On Wed, Mar 5, 2014 at 2:16 AM, Zane Bitter <zbitter at redhat.com> wrote:

> On 04/03/14 00:04, Georgy Okrokvertskhov wrote:
>
>>
>> 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.
>>
>
> 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.
>
> 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.
>
>
> cheers,
> Zane.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com
slagun at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140305/6375a3f4/attachment.html>