Hi Stan, thanks for sharing your thoughts about Murano and relation to TOSCA. I have added a few comments below.
> From: Stan Lagun <sla...@mirantis.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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 <zbit...@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@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@mirantis.com_______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
