Open Stack

Hi Stan,

thanks for sharing your thoughts about Murano and relation to TOSCA. I have
added a few comments below.

> From: Stan Lagun <slagun at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 05/03/2014 00:51
> Subject: Re: [openstack-dev] Incubation Request: Murano
>
> 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

Right, that's why we are doing the simple profile and YAML work now to
overcome those adoption issues.

> 2. TOSCA has no workflow language. TOSCA draft states that the
> language is indeed needed and recommends using BPEL or BPMN for that
matter.

Right, the goal of TOSCA was not to define a new workflow language but to
refer to existing ones. This does not mean, of course that other languages
than BPEL or BPMN cannot be used. We still consider standardization of such
a language out of scope of the TC, but if there is some widely adopted flow
language being implemented, e.g. in the course of Murano, I could imagine
that a community could use such a simpler language in an OpenStack
environment. Ideally though, such a simpler workflow language would be
translatable to a standard language like BPMN (or a subset of it) so those
who have a "real" process engine can consume the flow descriptions.

> 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.

We have been working on what we call a "plan portability API" that
describes what APIs a TOSCA container has to support so that portable flows
can access topology information. During the v1.0 time frame, though, we
focused on the declarative part (i.e. the topology model). But, yes I agree
that this part needs to be done so that also plans get portable. If you are
having experience in this area, it would be great to collaborate and see if
we can feed your input into the TOSCA effort.

> 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

I agree that BPEL and BPMN are very heavy and hard to use without tooling,
so no objection on looking at a lightweight alternative in the OpenStack
orchestration context.

> 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.

We have implementation for TOSCA in IBM, and I know that also HP, Fujitsu,
Huawei and Vnomic are supporting it (we did a public interop demo last
year). Also SAP provided an interop template (proof-of-concept only) for a
three-tier SAP system which we deployed on multiple engines. What is
missing is a broad community for now, but I think this could changed thru
collaboration in the OpenStack context.

> 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

Agree, and that's what we are trying to change by work in the OpenStack
community.
In addition, there is an open source implementation done by the University
of Stuttgart which is currently being released to an open source
organization (their tooling is going to eclipse, the runtime maybe to
Apache).

> 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

As I said earlier, we have implementations of the current XML spec, and we
are continueing to support XML. We started the YAML work for getting better
usability without tooling so it is easier to adopt TOSCA. The YAML
rendering will be a subset of the XML spec, and we will have full
compatibility. Please note that we are currently at working draft 1 only,
so there is still a lot of work to be done. Instead of writing the
paperwork down completely, we want to do implementation in parallel to let
implementation experience flow into the spec.

>
> 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 got the reasons why you started the Murano DSL and fully understand. It
would still be good, IMHO, to see if we can't find a way to agree on common
concepts that we express in a common language. Otherwise we will end up
with a few projects and DSLs that all try to cover very similar topics at
the end.
Don't get me wrong, I am not trying to say that TOSCA can be the solution
for everything (nor can be Murano IMO) and I am not saying that Murano
should be a 100% TOSCA compliant implementation. But for those parts that
fit, it should be desirable to have a common language. Other modules can
still sit around it.
And after all, it would be a two-way discussion: it's not about buying
everything that TOSCA defines, but there is also the chance to influence
TOSCA based on your experience.

That said, I would be happy to get into deeper discussions and see if we
can find alignment.

Regards,
Thomas

> 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_______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev