Open Stack

Hi Zane,

Thank you very much for this question.

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.

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:
Citations from [1]:
...
2. The definition of concrete plans, i.e. the definition of plans in any
process modeling language like BPMN or BPEL.
3. The definition of a language for defining plans (i.e. a new process
modeling language).
...
Plans in TOSCA understanding is something similar to workflows. This is
what we address by Murano workflow.

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.

Taking this into account lets review what we have in Murano as an
application package. Inside application package we have:
1. Application metadata which describes application, its relations and
properties
2. Heat templates snippets
3. Scripts for deployment
4. Workflow definitions

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.
The same section says the following:  "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." This
plan part which is out of scope of TOSCA is essentially what Murano adds as
a part of application definition.

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.

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.

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.

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.

TL;DR

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.

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.



[1] - TOSCA TC Scope of work:
https://www.oasis-open.org/committees/tosca/charter.php
[2] -  TOSCA standard document:
http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html
[3] - DSL discussion e-mail thread:
http://lists.openstack.org/pipermail/openstack-dev/2014-February/027938.html




On Mon, Mar 3, 2014 at 6:33 PM, Zane Bitter <zbitter at redhat.com> wrote:

> On 25/02/14 05:08, Thierry Carrez wrote:
>
>> The second challenge is that we only started to explore the space of
>> workload lifecycle management, with what looks like slightly overlapping
>> solutions (Heat, Murano, Solum, and the openstack-compatible PaaS
>> options out there), and it might be difficult, or too early, to pick a
>> winning complementary set.
>>
>
> 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).
>
> 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.
>
> cheers,
> Zane.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140303/48e3df65/attachment.html>