[openstack-dev] [Murano][Heat] MuranoPL questions?
thomas.herve at enovance.com
Tue Mar 25 10:32:04 UTC 2014
> Hi Thomas,
> I think we went to the second loop of the discussion about generic language
> concepts. Murano does not use a new language for the sole purpose of having
> parameters, constraints and polymorphism. These are generic concepts which
> are common for different languages, so keeping arguing about these generic
> concepts is just like a holy war like Python vs. C. Keeping these arguments
> is just like to say that we don't need Python as functions and parameters
> already exists in C which is used under the hood in Python.
> Yes Murano DSL have some generic concepts similar to HOT. I think this is a
> benefit as user will see the familiar syntax constructions and it will be a
> lower threshold for him to start using Murano DSL.
> In a simplified view Murano uses DSL for application definition to solve
> several particular problems:
> a) control UI rendering of Application Catalog
> b) control HOT template generation
> These aspects are not covered in HOT and probably should not be covered. I
> don't like an idea of expressing HOT template generation in HOT as it sounds
> like a creation another Lisp like language :-)
I'm not saying that HOT will cover all your needs. I think it will cover a really good portion. And I'm saying that for the remaining part, you can use an existing language and not create a new one.
> I don't think that your statement that most of the people in the community
> are against new DSL is a right summary. There are some disagreements how it
> should look like and what are the goals. You will be probably surprised but
> we are not the first who use DSL for HOT templates generation. Here is an
> e-mail thread right about Ruby based DSL used in IBM for the same purpose:
> The term "Orchestration" is quite generic. Saying that orchestration should
> be Heat job sounds like a well know Henry Ford's phrase "You can have any
> colour as long as it's black.".
That worked okay for him :).
> I think this is again a lack of understanding of the difference between
> Orchestration program and Heat project. There are many aspects of
> Orchestration and OpenStack has the Orchestration program for the projects
> which are focused on some aspects of orchestration. Heat is one of the
> project inside Orchestration program but it does not mean that Heat should
> cover everything. That is why we discussed in this thread how workflows
> aspects should be aligned and how they should be placed into this
> Orchestration program.
Well, today Heat is the one and only program in the Orchestration program. If and when you have orchestration needs not covered, we are there to make sure Heat is not the best place to handle them. The answer will probably not Heat forever, but we need good use cases to delegate those needs to another project.
More information about the OpenStack-dev