[openstack-dev] [Murano][Heat] MuranoPL questions?
gokrokvertskhov at mirantis.com
Tue Mar 25 11:22:22 UTC 2014
On Tue, Mar 25, 2014 at 3:32 AM, Thomas Herve <thomas.herve at enovance.com>wrote:
> > Hi Thomas,
> > I think we went to the second loop of the discussion about generic
> > concepts. Murano does not use a new language for the sole purpose of
> > parameters, constraints and polymorphism. These are generic concepts
> > are common for different languages, so keeping arguing about these
> > concepts is just like a holy war like Python vs. C. Keeping these
> > 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.
> > don't like an idea of expressing HOT template generation in HOT as it
> > 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.
As a user can't run arbitrary python code in openstack we used Python
language to create a new API for the remaining parts. This API service
accepts a yaml based description of what should be done. There is no
intention to create a new generic programming language. We used OpenStack
approach and created a service for specific functions around Application
Catalog features. Due to dynamic nature of applications we had to add a bit
of dynamics to the service input just because of the same reason why Heat
> > I don't think that your statement that most of the people in the
> > are against new DSL is a right summary. There are some disagreements how
> > should look like and what are the goals. You will be probably surprised
> > 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
> > The term "Orchestration" is quite generic. Saying that orchestration
> > 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 :).
Not really. The world acknowledged his inventions and new approaches. Other
manufacturers adopted his ideas and moved forward, providing more variety,
while Ford stuck with his model-T, which was very successful though. The
history shows that variety won the battle over single approach and now we
have different colors, shapes, engines :-)
> > 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
> > which are focused on some aspects of orchestration. Heat is one of the
> > project inside Orchestration program but it does not mean that Heat
> > 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.
That is exactly the reason why we have these discussions :-) We have the
use cases for new functionality and we are trying to find a place for it.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
OpenStack Platform Products,
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev