<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">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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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 class="im"><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>_______________________________________________<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"><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>