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