Open Stack

Hi,

Here is an etherpad page with current Murano status
http://etherpad.openstack.org/p/murano-incubation-status.

Thanks
Georgy


On Mon, Mar 3, 2014 at 9:04 PM, Georgy Okrokvertskhov <
gokrokvertskhov at mirantis.com> wrote:

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



-- 
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/20140304/ad350c6c/attachment.html>