On 03/25/2014 03:32 AM, Thomas Herve 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.
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 :).
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.
Thomas,
I see a natural expansion of the Orchestration codebase in spinning our
autoscaling work that is tightly integrated and woven into Heat into a
separate repo under the orchestration program. Note this is not an
expansion in scope, as autoscaling is already part of the orchestration
program's scope.
I could also see how workflow could fit into the orchestration program,
and if it did, it would definitely need to be a different code base then
Heat proper. IMO the autoscaling built into Heat makes Heat a bit more
difficult to understand and maintain. I don't think we really want to
complicate that with more stuff like workflows and imperative
programming. After you having been a champion of the HOT DSL, I suspect
you are not keen to jam imperative things into it, given how nice and
tidy it is at present :)
Now RE the multiple DSLs, I have heard some folks mention they don't
want multiple DSLs for different jobs in the orchestration program. I
have provided a cost benefit analysis of one dsl vs multiple DSLs in
several previous threads. I found the cost of a unified DSL to be
unacceptable to the mission of Heat. If folks reallly feel differently,
please feel free to refute my points :)
Regards
-steve
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
