[openstack-dev] [Murano][Heat] MuranoPL questions?

Georgy Okrokvertskhov 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
> 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.

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
uses templates.

> > 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:
> >
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/026606.html
> >
> > 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 :).

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

> --
> Thomas
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Georgy Okrokvertskhov
OpenStack Platform Products,
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/20140325/c0a55aa9/attachment.html>

More information about the OpenStack-dev mailing list