<div dir="ltr">I mentioned on IRC the other day that I find this problem fundamentally un-interesting, and I'll explain why. I should note that this is strictly my personal opinion, probably in no way resembles the views of anyone else involved in Heat, and is unlikely to persuade anyone.<br>

<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This guy, your hypothetical typical Murano user. Two minutes ago he didn't know what OpenStack is, or that Drupal requires a database. But now it's suddenly *imperative* that he be able to swap out MySQL for Postgres in this pre-packaged application???<br>


<br>
This problem is not interesting to me because nobody has this problem.<br>
<br>
Except maybe bored micromanagers looking to mark their territory by putting their stamp on some part of a project. (See <a href="http://programmers.stackexchange.com/a/122148" target="_blank">http://programmers.<u></u>stackexchange.com/a/122148</a>.) And I'm not interested in them either.<br>


<br>
(Looking up the appropriate Dilbert references to insert here is left as an exercise for the reader.)<br>
<br>
If the developer wants to support a MySQL version and a Postgres version, let them release two versions. They will know, of course, that the number of things they need to test increases combinatorially with the number of options they provide, and may well not be as keen as you think to make everything customisable. (Of course the right answer here, and the one that substantially all application authors will choose, is to use whatever built-in DBaaS the operator provides.)<div class="">

<br></div></blockquote><div><br></div><div>Sorry for being unclear. I just merged several use cases into one to demonstrate what should be IMO possible to do rather than why it is important. There are guys that don't know or don't care what components application is made of. There are those who do. We want Murano to be useful for both of them (although it is no doubt that advanced guys may chose to go with the Heat of puppet). I can easily imagine cases when I do care on database like Marconi case where there is a trade of between high performance with AGPL MongoDB and low-performance regular MySQL. Or maybe I have set up expensive Oracle database cluster with HA, backups and everything and I prefer applications to use it rather than install private instance of MySQL (have you ever seen applications that uses Oracle by default?). The bigger environment you have (in terms of how many application it comprises of) the more chances you want to swap/merge some components to make less moving part, to increase resource utilization or to reduce TOC, Anyway this is not sole purpose of Murano but a nice bonus that you have because of system flexibility. <br>

</div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In Heat HOT developer is the user. But in Murano those are completely<br>
different roles. There are developers that write application definitions<br>
</blockquote>
<br></div>
I don't really see a difference. In both HOT and Murano the person launching the application may or may not be the same person who wrote the application definition. There's no reason e.g. that both should not be made available in a Glance-like application catalog.<div class="">

<br></div></blockquote><div>Both should be in Glance, no doubt. The difference is in who is responsible for the template. In Heat you can take and use HOT template written by someone else and if it doesn't completely fits your needs you can always modify it. Anyway as soon as you submit it the system (Heat) does not distinguish or care how that HOT was obtained. In Murano those roles are separated by design. There are different interfaces for publishing application to AppCatalog and building environment from applications that are already in catalog. They controlled by different ACLs. For example cloud provider (IT department in case of private cloud) may choose not to allow users to publish applications and let them to deploy just those apps that cloud provider has chosen.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""></div><br>
<div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And let users build environments of any<br>
complexity from small components while providing reasonable default so<br>
that one-click deployment would also be possible. And such system to be<br>
useful the design process need to be guided and driven by UI. System<br>
must know what combination of components are possible and what are not<br>
and not let user create Microsoft IIS hosted on Fedora.<br>
</blockquote>
<br></div>
If I may go all editorial on you again, this sounds like the same thing we've been hearing since the 1970s: "When everything is object oriented, non-technical users will be able to program just by plugging together existing chunks of code." Except it hasn't ever worked. 35+ years. No results.</blockquote>

<div><br></div><div>Agree. I know it sounds like marketing bullshit. I never believed myself this would work for programming. It never worked because OOP approach doesn't save you from writing code. But there domains when component development did worked. Like CAD design. I don't see why this wouldn't work for deployment/ALM. Anyway I believe we need to try because it is better to fail than even not try. But if we succeed this ma be a breakthrough. You know there are so many systems available that can bring you WordPress or MySQL with several mouse clicks and most of them work fine with OpenStack. So what is the point of building just another JuJu? My belief is that we have to be innovative and try to do what other couldn't achieve or just step out. This is just my personal opinion and motivation.  <br>

</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
5. Mistral does not need all that OOP stuff, inheritance, constraints<br>
etc. And in practice it is very hard to separate declarations from the<br>
workflow code as they are very coupled in their nature<br>
</blockquote>
<br></div>
Why? Because of all the $this stuff? From the few I have looked at, all of the stuff that is being done imperatively in the workflows using the object's properties could have been done declaratively in Heat, just passing the properties as parameters to a template.<div class="">

<br></div></blockquote><div><br></div><div>Because code and data are tightly connected. Since the classes can reference each other you can have expressions like $this.ref1.ref2.property e.g. navigate in object model. But how do you do that if you offload execution to the system that is not aware of you object model and works with flat data? (not saying it is completely undoable but this may be very hard and not a good idea anyway). Properties have contracts. If you say that your property is an array of integers then you should not let assign strings or use it as it was scalar. Thus execution engine (Mistral in this case) need to be aware of data typing and contracts. And then comes inheritance - property may be introduced in derived class and is not available via reference to his parent class. There is also method name resolution, access control for properties and many more. Thats all because declarations and imperative code are not separate things but one single programming language. And while it may be reasonable to have imperative workflow in Mistral I don't feel that Mistral also wants to have all that OOP declarations. Initially we wanted to translate MuranoPL into Mistral DSL that is much simpler and not object-oriented similar to how you compile OOP C++ to non-OOP assembly. But it turns to be too difficult to implement at current stage.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
6. DSL is a hart and brain of Murano. It is the most vital part of it.<br>
You cannot develop system of such level as Murano without having control<br>
over it. Any decision taken by Mistral team can become fatal for Murano.<br>
</blockquote>
<br></div>
You depend on parts of HOT already, don't you have the same issue with Heat?<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyway I hope that some day we will be able to somehow merge our<br>
DSLs/codebase/whatever<br>
</blockquote>
<br></div>
This seems unlikely to happen by accident.<br>
<br>
I think the difference between the approach you've taken and what I'm advocating for is that it's very top-down. Start with a problem, design a DSL around it, stick it in OpenStack and "hope that some day we will be able to somehow merge". I would much prefer a more bottom-up approach. We have these tools already (or in the case of Mistral, we're in the process of developing them)... in what ways can we extend them incrementally to help them cover a wider range of use cases? (Folks who were around a year ago when talk of moving Heat closer to TOSCA first began will tell you that I have been pretty consistent in pushing this approach.)</blockquote>

<div><br><br></div><div>You're absolutely right. The problem with bottom-up approach is that it <span id="result_box" class="" lang="en"><span class="">pulls you down. Once you start doing 'small thing' and get your first users there are very few chances for you to make revolutionary changes and step forward. You always need to maintain backward compatibility and make everybody happy. If you started your project as a calculator it will probably never become MATLAB even if you had it in mind. Just because most of your contributors would be happy with calculator and it is calculator that your customers have bought and not MATLAB. We can definitely start doing something simpler than what we want. And if we lower the bar we would not need MuranoPL and all that but I afraid we would never have a change to bring it back. Consider what it would take now to replace HOT with something completely different if you decide to. There is also a big players on the market outside OpenStack community.  And while we are going from the bottom and hoping to grow some day big companies release their AppEngines, CloudFoundries and BlueMixes that catch up customers and have WOW effect and nobody cares that they are so cool just on the surface. Even if we grow our calculator to MATLAB level it just would be too late then. Again this is just my opinion and this very depends on what are the priorities and goals and my bosses may not agree with me here. Anyway top-bottom approach doesn't mean we cannot merge our efforts other than accidentally. If we start collaborate on early stages and coordinate our efforts I don't see why it shouldn't happen.<br>

</span></span></div><div><br><br></div><div>I also agree with Thomas on that TOSCA is a perfect place for collaboration and Murano should become involved as soon as it is possible <br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class=""><div class="h5"><br>
<br>
cheers,<br>
Zane.<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours<br>

Stanislav (Stan) Lagun<br>Senior Developer<br>Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><span style="font-size:10pt;font-family:"Arial","sans-serif"" lang="EN-US">35b/3, Vorontsovskaya
St.</span><br>Moscow, Russia<br>Skype: stanlagun<br><a href="http://www.mirantis.com/" target="_blank">www.mirantis.com</a><br><a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a></span></span></div>


</div></div>