<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 26, 2014 at 11:25 AM, Keith Bray <span dir="ltr"><<a href="mailto:keith.bray@rackspace.com" target="_blank">keith.bray@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>
<br>
On 3/25/14 11:55 AM, "Ruslan Kamaldinov" <<a href="mailto:rkamaldinov@mirantis.com">rkamaldinov@mirantis.com</a>> wrote:<br>
<br>
>* Murano DSL will focus on:<br>
> a. UI rendering<br>
<br>
<br>
</div>One of the primary reasons I am opposed to using a different DSL/project<br>
to accomplish this is that the person authoring the HOT template is<br>
usually the system architect, and this is the same person who has the<br>
technical knowledge to know what technologies you can swap in/out and<br>
still have that system/component work, so they are also the person who<br>
can/should define the "rules" of what component building blocks can and<br>
can't work together. There has been an overwhelmingly strong preference<br>
from the system architects/DevOps/ApplicationExperts I [1] have talked to<br>
for the ability to have control over those rules directly within the HOT<br>
file or immediately along-side the HOT file but feed the whole set of<br>
files to a single API endpoint. I'm not advocating that this extra stuff<br>
be part of Heat Engine (I understand the desire to keep the orchestration<br>
engine clean)... But from a barrier to adoption point-of-view, the extra<br>
effort for the HOT author to learn another DSL and use yet another system<br>
(or even have to write multiple files) should not be underestimated.<br>
These people are not OpenStack developers, they are DevOps folks and<br>
Application Experts. This is why the Htr[2] project was proposed and<br>
threads were started to add extra data to HOT template that Heat engine<br>
could essentially ignore, but would make defining UI rendering and<br>
component connectivity easy for the HOT author.<br></blockquote><div><br></div><div>I think that this is a wrong way to go. First of all there is an issue with separation of concerns as you will have one super-template which will describe the whole world. UI part is only one of the use cases, but when Murano will need some extra parameter will it go to HOT? When Solum will need to define application build sequence to make an app binary from source will this also go to HOT?</div>
<div><br></div><div>I think the reason for such talks was the fact that Heat engine accepts only a single file as an input. Which is completely understandable as Heat engine is designed to process a template which describes a set of resources and their relations.</div>
<div><br></div><div>While we talk with our customers who want use Murano they are happy to have multiple files keep each one small and simple. In Murano UI definition is a separate file and application developer can have multiple UI file definitions to quickly change look and feel without changing the deploymen template part of application at all. Heat supports template nesting, this is no obvious how the UI for this case will be rendered as this nesting will be processed by Heat engine and final set of resources will be produced by engine.</div>
<div><br></div><div>I don't see a big difference in learning between one huge DSL which covers the all possible aspects and a set of small simpler DSLs focused on each specific area. Having one big DSL is worse as the user can construct some complex structures mixing the DSL functions from different are. It will be a nightmare to create an engine which will validate and process such template.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'm all for contributions to OpenStack, so I encourage the Murano team to<br>
continue doing its thing if they find it adds value to themselves or<br>
others. However, I'd like to see the Orchestration program support the<br>
surrounding things the users of the Heat engine want/need from their cloud<br>
system instead of having those needs met by separate projects seeking<br>
incubation. There are technical ways to keep the core engine "clean" while<br>
having the Orchestration Program API Service move up the stack in terms of<br>
cloud user experience.<br></blockquote><div><br></div><div>I just think this is a conceptually wrong. The whole idea of OpenStack to have a clean set of API\components focused on specific functionality. Cloud users want to have VMs with attached volumes and networks but is does not mean that it should be single service in OpenStack. This is a power of OpenStack which shows that the proper separation of concern and having multiple services is a right way which allow one to move forward fast making the development process for each service very effective due to narrow scope and functionality focus.</div>
<div><br></div><div>I am glad to hear that you want to have something higher up to stack that the current available functionality. I think this support our observation of a huge demand for such higher level functionality in OpenStack. At the same time I am against the proposed way of doing that by extending the Orchestration program mission moving it to upper levels. Having clean layers responsible for particular area is a benefit and strong side of OpenStack from its global architecture view point.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
> b. HOT generation<br>
> c. Setup other services (like put Mistral tasks to Mistral and bind<br>
> them with events)<br>
><br>
>Speaking about new DSL for Murano. We're speaking about Application<br>
>Lifecycle<br>
>Management. There are a lot of existing tools - Heat/HOT, Python, etc,<br>
>but none<br>
>of them was designed with ALM in mind as a goal.<br>
<br>
</div>Solum[3] is specifically designed for ALM and purpose built for<br>
OpenStack... It has declared that it will generate HOT templates and setup<br>
other services, including putting together or executing supplied workflow<br>
definition (using Mistral if applicable). Like Murano, Solum is also not<br>
an OpenStack incubated project, but it has been designed with community<br>
collaboration (based on shared pain across multiple contributors) with the<br>
ALM goal in mind from the very beginning.<br></blockquote><div><br></div><div>I think that the HOT template generation is not a key feature of Solum. It is just a details of implementation. Other services like TripleO also generates Heat templates but it does not mean that it is their primary goal. </div>
<div><br></div><div>ALM is a broad term. I think Solum has a different area of responsibility covering the Application Development area which does covered in OpenStack yet. </div><div>The high level goals listed on Solum.io are:</div>
<ul><li>Provisioning Speed<br></li><li>CI/CD<br></li><li>Git Push<br></li><li>Integration with common IDE’s (Eclipse, IntelliJ, etc)<br></li><li>Application lifecycle management(connected environments – Dev, Test, Prod)<br>
</li></ul><div>Given that I don't see the huge overlap here with Murano functionality as even if Solum stated that as a part of solution Heat template will be generated it does not necessarily mean that Solum itself will do this. From what is listed on the Solum page, in Solum sense - ALM is a way how the application build from source promoted between different CI\CD environments Dev, QA, Stage, Production. Solum can use other service to do this keeping its own focus on the target area. Specifically to the environments - Solum can use Murano environments which for Murano is just a logical unity of multiple applications. Solum can add CI\CD specific stuff on top of it keeping using Murano API for the environment management under the hood.</div>
<div>Again, this is a typical OpenStack approach to have different services integrated to achieve the larger goal, keeping services itself very focused.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
-Keith<br>
<br>
<br>
[1] I regularly speak with DevOps, Application Specialists, and cloud<br>
customers, specifically about Orchestration and Heat.. HOT is somewhat<br>
simple enough for the most technical of them (DevOps & App Specialists) to<br>
grasp and have interest in adopting, but their is strong push back from<br>
the folks I talk to about having to learn one more thing... Since Heat<br>
adopters are exactly the same people who have the knowledge to define the<br>
overall system capabilities including component connectivity and how UI<br>
should be rendered, I'd like to keep it simple for them. The more we can<br>
do to have the Orchestration service look/feel like one thing (even if<br>
it's Engine + Other things under the hood), or reuse other OpenStack core<br>
components (e.g. Glance) the better for adoption.<br>
[2] <a href="https://wiki.openstack.org/wiki/Heat/htr" target="_blank">https://wiki.openstack.org/wiki/Heat/htr</a><br>
[3] <a href="http://solum.io" target="_blank">http://solum.io</a><br>
<div class=""><div class="h5"><br>
<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>