<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 3:32 AM, Thomas Herve <span dir="ltr"><<a href="mailto:thomas.herve@enovance.com" target="_blank">thomas.herve@enovance.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
> Hi Thomas,<br>
><br>
> I think we went to the second loop of the discussion about generic language<br>
> concepts. Murano does not use a new language for the sole purpose of having<br>
> parameters, constraints and polymorphism. These are generic concepts which<br>
> are common for different languages, so keeping arguing about these generic<br>
> concepts is just like a holy war like Python vs. C. Keeping these arguments<br>
> is just like to say that we don't need Python as functions and parameters<br>
> already exists in C which is used under the hood in Python.<br>
><br>
> Yes Murano DSL have some generic concepts similar to HOT. I think this is a<br>
> benefit as user will see the familiar syntax constructions and it will be a<br>
> lower threshold for him to start using Murano DSL.<br>
><br>
> In a simplified view Murano uses DSL for application definition to solve<br>
> several particular problems:<br>
> a) control UI rendering of Application Catalog<br>
> b) control HOT template generation<br>
><br>
> These aspects are not covered in HOT and probably should not be covered. I<br>
> don't like an idea of expressing HOT template generation in HOT as it sounds<br>
> like a creation another Lisp like language :-)<br>
<br>
</div>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.<br></blockquote>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
> I don't think that your statement that most of the people in the community<br>
> are against new DSL is a right summary. There are some disagreements how it<br>
> should look like and what are the goals. You will be probably surprised but<br>
> we are not the first who use DSL for HOT templates generation. Here is an<br>
> e-mail thread right about Ruby based DSL used in IBM for the same purpose:<br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-February/026606.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-February/026606.html</a><br>
><br>
> The term "Orchestration" is quite generic. Saying that orchestration should<br>
> be Heat job sounds like a well know Henry Ford's phrase "You can have any<br>
> colour as long as it's black.".<br>
<br>
</div>That worked okay for him :).<br></blockquote><div><br></div><div>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 :-)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
> I think this is again a lack of understanding of the difference between<br>
> Orchestration program and Heat project. There are many aspects of<br>
> Orchestration and OpenStack has the Orchestration program for the projects<br>
> which are focused on some aspects of orchestration. Heat is one of the<br>
> project inside Orchestration program but it does not mean that Heat should<br>
> cover everything. That is why we discussed in this thread how workflows<br>
> aspects should be aligned and how they should be placed into this<br>
> Orchestration program.<br>
<br>
</div>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.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
--<br>
Thomas<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div>
</div></div>