<div dir="ltr"><div><div><div><div>It seems to me that something is missing in our discussion.<br><br></div>If something depends on something else there must be a definition of that something. It is clear that it is not the case that one instance depends on another but one application depends on another application. But there is no such thing as application (service, whatever) in HOT templates. Only low-level resources. And even resources cannot be grouped to some application scope because typical HOT template has resources that are shared between several applications (network, security groups etc.). It also possible to have several applications sharing a single VM instance. That brings us to a conclusion that applications and resources cannot be mixed in the same template on the same level of abstraction.<br>

<br></div>Now suppose we did somehow established the dependency between two applications. But this dependency is out of scope of particular HOT template. Thats because HOT template says what user whishes to install. But a dependency between applications is an attribute of applications themselves, not the particular deployment. For example WordPress requires database. It always does. Not that it requires it within this particular template but a a universal rule. In Murano we call it data vs. metadata separation. If there is a metadata that says "WordPress requires DB" then you not just only don't have to repeat it in each template but you cannot even ask a system to deploy WordPress without DB.<br>

<br></div>So the question is maybe we need to think about applications/services and their metadata before going into workflow orchestration? Otherwise the whole orchestration would be reinvented time and time again with each new HOT template.<br>

<br></div>What are your thoughts on this?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 11:37 PM, Georgy Okrokvertskhov <span dir="ltr"><<a href="mailto:gokrokvertskhov@mirantis.com" target="_blank">gokrokvertskhov@mirantis.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Lakshminaraya,<br><div><br></div><div>Thank you for bringing your use case and your thought here. That is exactly tried to achieve in Murano project. </div>

<div>There are important  aspects you highlighted. Sometime resource model is two high level to describe deployment process. If you start to use more granular approach to have defined steps of deployment you will finish with workflow approach where you have fine control of deployment process but description will be quite complex. </div>


<div><br></div><div>I think the HOT approach is to provide a simple way do describe you deployment which consists of solid bricks (resources). If you are using standard resources you can easily create a simple HOT template for your deployment. If you need some custom resource you basically have two options - create new resource class and hide all complexity inside the code or use some workflows language to describe all steps required. The first approach is currently supported by Heat. We have an experience of creating new custom resources for orchestration deployment to specific IT infrastructure with specific hardware and software.</div>


<div><br></div><div>Right now we are trying to figure out the possibility of adding workflows to HOT. It looks like adding workflows language directly might harm HOT simplicity by overloaded DSL syntax and structures.  </div>


<div><br></div><div>I actually see the value in Steve's idea to have specific resource or resource set to call workflows execution on external engine. In this case HOT template will be still pretty simple as all workflow details will be hidden, but still manageable without code writing. </div>


<div><br></div><div>Thanks</div><div>Gosha</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Oct 9, 2013 at 11:31 AM, Lakshminaraya Renganarayana <span dir="ltr"><<a href="mailto:lrengan@us.ibm.com" target="_blank">lrengan@us.ibm.com</a>></span> wrote:<br>


</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div>
<p><tt><font>Steven Hardy <<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>> wrote on 10/09/2013 05:24:38 AM:</font></tt></p><div><tt><font><br>
<br>
> <br>
> So as has already been mentioned, Heat defines an internal workflow, based<br>
> on the declarative model defined in the template.<br>
> <br>
> The model should define dependencies, and Heat should convert those<br>
> dependencies into a workflow internally.  IMO if the user also needs to<br>
> describe a workflow explicitly in the template, then we've probably failed<br>
> to provide the right template interfaces for describing depenendencies.<br>
</font></tt></div><br>
<tt><font>I agree with Steven here, models should define the dependencies and Heat</font></tt><br>
<tt><font>should realize/enforce them. An important design issue is granularity at</font></tt><br>
<tt><font>which dependencies are defined and enforced. I am aware of the wait-condition</font></tt><br>
<tt><font>and signal constructs in Heat, but I find them a bit low-level as they are prone</font></tt><br>
<tt><font>to the classic dead-lock and race condition problems.  I would like to have </font></tt><br>
<tt><font>higher level constructs that support finer-granularity dependences which</font></tt><br>
<tt><font>are needed for software orchestration. Reading through the various disucssion</font></tt><br>
<tt><font>on this topic in this mailing list, I see that many would like to have such</font></tt><br>
<tt><font>higher level constructs for coordination.</font></tt><br>
<br>
<tt><font>In our experience with software orchestration using our own DSL and also with </font></tt><br>
<tt><font>some extensions to Heat, we found that the granularity of VMs or Resources to be </font></tt><br>
<tt><font>too coarse for defining dependencies for software orchestration. For example, consider </font></tt><br>
<tt><font>a two VM app, with VMs vmA, vmB, and a set of software components (ai's and bi's) </font></tt><br>
<tt><font>to be installed on them:</font></tt><br>
<br>
<tt><font>vmA = base-vmA + a1 + a2 + a3</font></tt><br>
<tt><font>vmB = base-vmB + b1 + b2 + b3</font></tt><br>
<br>
<tt><font>let us say that software component b1 of vmB, requires a config value produced by</font></tt><br>
<tt><font>software component a1 of vmA. How to declaratively model this dependence? Clearly,</font></tt><br>
<tt><font>modeling a dependence between just base-vmA and base-vmB is not enough. However,</font></tt><br>
<tt><font>defining a dependence between the whole of vmA and vmB is too coarse. It would be ideal</font></tt><br>
<tt><font>to be able to define a dependence at the granularity of software components, i.e., </font></tt><br>
<tt><font>vmB.b1 depends on vmA.a1. Of course, it would also be good to capture what value </font></tt><br>
<tt><font>is passed between vmB.b1 and vmA.a1, so that the communication can be facilitated</font></tt><br>
<tt><font>by the orchestration engine.   </font></tt><br>
<br>
<tt><font>We found that such finer granular modeling of the dependencies provides two valuable benefits:</font></tt><br>
<br>
<tt><font>1. Faster total (resources + software setup) deployment time. For the example described</font></tt><br>
<tt><font>above, a coarse-granularity dependence enforcer would start the deployment of base-vmB after</font></tt><br>
<tt><font>vmA + a1 + a2 + a3 is completed, but a fine-granularity dependence enforcer would start base-vmA</font></tt><br>
<tt><font>and base-vmB concurrently, and then suspend the execution of vmB.b1 until vmA.a1 is complete and then </font></tt><br>
<tt><font>let the rest of deployment proceed concurrently, resulting in a faster completion.</font></tt><br>
<br>
<tt><font>2. More flexible dependencies. For example, mutual dependencies between resources, </font></tt><br>
<tt><font>which can be satisfied when orchestrated at a finer granularity. Using the example described</font></tt><br>
<tt><font>above, fine-granularity would allow vmB.b1 depends_on vmA.a1 and also vmA.a3 depends_on vmB.b2,</font></tt><br>
<tt><font>but coarse-granularity model would flag this as a cyclic dependence.</font></tt><br>
<br>
<tt><font>There are two aspects that needs support:</font></tt><br>
<br>
<tt><font>1. Heat/HOT template level constructs to support declarative expression of such fine-granularity</font></tt><br>
<tt><font>dependencies and the values communicated / passed for the dependence.</font></tt><br>
<tt><font>2. Support from Heat engine / analyzer in supporting the runtime ordering, coordination between</font></tt><br>
<tt><font>resources, and also the communication of the values. </font></tt><br>
<br>
<tt><font>What are your thoughts? </font></tt><p></p></div><br></div></div><div class="im">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></div></blockquote></div><br><br clear="all"><div class="im"><div><br></div>-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<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<br>
</div></div>
<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>
<br></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:10.0pt;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>