On Tue, Mar 25, 2014 at 3:32 AM, Thomas Herve <thomas.he...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
