<html><body>
<p><tt><font size="2">Thomas Spatzier <thomas.spatzier@de.ibm.com> wrote on 10/21/2013 08:29:47 AM:<br>
<br>
> you mentioned an example in your original post, but I did not find it. Can<br>
> you add the example?<br>
</font></tt><br>
<tt><font size="2">Hi Thomas,</font></tt><br>
<br>
<tt><font size="2">Here is the example I used earlier:</font></tt><br>
<br>
<tt><font size="2">For example, consider </font></tt><br>
<tt><font size="2">a two VM app, with VMs vmA, vmB, and a set of software components (ai's and bi's) </font></tt><br>
<tt><font size="2">to be installed on them:</font></tt><br>
<br>
<tt><font size="2">vmA = base-vmA + a1 + a2 + a3</font></tt><br>
<tt><font size="2">vmB = base-vmB + b1 + b2 + b3</font></tt><br>
<br>
<tt><font size="2">let us say that software component b1 of vmB, requires a config value produced by</font></tt><br>
<tt><font size="2">software component a1 of vmA. How to declaratively model this dependence? Clearly,</font></tt><br>
<tt><font size="2">modeling a dependence between just base-vmA and base-vmB is not enough. However,</font></tt><br>
<tt><font size="2">defining a dependence between the whole of vmA and vmB is too coarse. It would be ideal</font></tt><br>
<tt><font size="2">to be able to define a dependence at the granularity of software components, i.e., </font></tt><br>
<tt><font size="2">vmB.b1 depends on vmA.a1. Of course, it would also be good to capture what value </font></tt><br>
<tt><font size="2">is passed between vmB.b1 and vmA.a1, so that the communication can be facilitated</font></tt><br>
<tt><font size="2">by the orchestration engine. </font></tt><br>
<br>
<br>
<tt><font size="2">Thanks,<br>
LN</font></tt><br>
<br>
<tt><font size="2">> <br>
> Lakshminaraya Renganarayana <lrengan@us.ibm.com> wrote on 18.10.2013<br>
> 20:57:43:<br>
> > From: Lakshminaraya Renganarayana <lrengan@us.ibm.com><br>
> > To: OpenStack Development Mailing List<br>
> <openstack-dev@lists.openstack.org>,<br>
> > Date: 18.10.2013 21:01<br>
> > Subject: Re: [openstack-dev] [Heat] A prototype for cross-vm<br>
> > synchronization and communication<br>
> ><br>
> > Just wanted to add a couple of clarifications:<br>
> ><br>
> > 1. the cross-vm dependences are captured via the read/writes of<br>
> > attributes in resources and in software components (described in<br>
> > metadata sections).<br>
> ><br>
> > 2. these dependences are then realized via blocking-reads and writes<br>
> > to zookeeper, which realizes the cross-vm synchronization and<br>
> > communication of values between the resources.<br>
> ><br>
> > Thanks,<br>
> > LN<br>
> ><br>
> ><br>
> > Lakshminaraya Renganarayana/Watson/IBM@IBMUS wrote on 10/18/2013 02:45:01<br>
> PM:<br>
> ><br>
> > > From: Lakshminaraya Renganarayana/Watson/IBM@IBMUS<br>
> > > To: OpenStack Development Mailing List<br>
> <openstack-dev@lists.openstack.org><br>
> > > Date: 10/18/2013 02:48 PM<br>
> > > Subject: [openstack-dev] [Heat] A prototype for cross-vm<br>
> > > synchronization and communication<br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > > In the last Openstack Heat meeting there was good interest in<br>
> > > proposals for cross-vm synchronization and communication and I had<br>
> > > mentioned the prototype I have built. I had also promised that I<br>
> > > will post an outline of the prototype ... Here it is. I might have<br>
> > > missed some details, please feel free to ask / comment and I would<br>
> > > be happy to explain more.<br>
> > > ---<br>
> > > Goal of the prototype: Enable cross-vm synchronization and<br>
> > > communication using high-level declarative description (no wait-<br>
> > > conditions) Use chef as the CM tool.<br>
> > ><br>
> > > Design rationale / choices of the prototype (note that these were<br>
> > > made just for the prototype and I am not proposing them to be the<br>
> > > choices for Heat/HOT):<br>
> > ><br>
> > > D1: No new construct in Heat template<br>
> > > => use metadata sections<br>
> > > D2: No extensions to core Heat engine<br>
> > > => use a pre-processor that will produce a Heat template that the<br>
> > > standard Heat engine can consume<br>
> > > D3: Do not require chef recipes to be modified<br>
> > > => use a convention of accessing inputs/outputs from chef node[][]<br>
> > > => use ruby meta-programming to intercept reads/writes to node[][]<br>
> > > forward values<br>
> > > D4: Use a standard distributed coordinator (don't reinvent)<br>
> > > => use zookeeper as a coordinator and as a global data space for<br>
> > communciation<br>
> > ><br>
> > > Overall, the flow is the following:<br>
> > > 1. User specifies a Heat template with details about software config<br>
> > > and dependences in the metadata section of resources (see step S1<br>
> below).<br>
> > > 2. A pre-processor consumes this augmented heat template and<br>
> > > produces another heat template with user-data sections with cloud-<br>
> > > init scripts and also sets up a zookeeper instance with enough<br>
> > > information to coordinate between the resources at runtime to<br>
> > > realize the dependences and synchronization (see step S2)<br>
> > > 3. The generated heat template is fed into standard heat engine to<br>
> > > deploy. After the VMs are created the cloud-init script kicks in.<br>
> > > The cloud init script installs chef solo and then starts the<br>
> > > execution of the roles specified in the metadata section. During<br>
> > > this execution of the recipes the coordination is realized (see<br>
> > > steps S2 and S3 below).<br>
> > ><br>
> > > Implementation scheme:<br>
> > > S1. Use metadata section of each resource to describe (see<br>
> > attached example)<br>
> > > - a list of roles<br>
> > > - inputs to and outputs from each role and their mapping to resource<br>
> > > attrs (any attr)<br>
> > > - convention: these inputs/outputs will be through chef node attrs node<br>
> [][]<br>
> > ><br>
> > > S2. Dependence analysis and cloud init script generation<br>
> > ><br>
> > > Dependence analysis:<br>
> > > - resolve every reference that can be statically resolved using<br>
> > > Heat's fucntions (this step just uses Heat's current dependence<br>
> > > analysis -- Thanks to Zane Bitter for helping me understand this)<br>
> > > - flag all unresolved references as values resolved at run-time at<br>
> > > communicated via the coordinator<br>
> > ><br>
> > > Use cloud-init in user-data sections:<br>
> > > - automatically generate a script that would bootstrap chef and will<br>
> > > run the roles/recipes in the order specified in the metadata section<br>
> > > - generate dependence info for zookeeper to coordinate at runtime<br>
> > ><br>
> > > S3. Coordinate synchronization and communication at run-time<br>
> > > - intercept reads and writes to node[][]<br>
> > > - if it is a remote read, get it from Zookeeper<br>
> > > - execution will block till the value is available<br>
> > > - if write is for a value required by a remote resource, write the<br>
> > > value to Zookeeper<br>
> > ><br>
> > > The prototype is implemented in Python and Ruby is used for chef<br>
> > > interception.<br>
> > ><br>
> > > There are alternatives for many of the choices I have made for<br>
> theprototype:<br>
> > > - zookeeper can be replaced with any other service that provides a<br>
> > > data space and distributed coordination<br>
> > > - chef can be replaced by any other CM tool (a little bit of design<br>
> > > / convention needed for other CM tools because of the interception<br>
> > > used in the prototype to catch reads/writes to node[][])<br>
> > > - the whole dependence analysis can be integrated into the Heat's<br>
> > > dependence analyzer<br>
> > > - the component construct proposed recently (by Steve Baker) for<br>
> > > HOT/Heat can be used to specify much of what is specified using the<br>
> > > metadata sections in this prototype.<br>
> > ><br>
> > > I am interested in using my experience with this prototype to<br>
> > > contribute to HOT/Heat's cross-vm synchronization and communication<br>
> > > design and code. I look forward to your comments.<br>
> > ><br>
> > > Thanks,<br>
> > > LN_______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > OpenStack-dev@lists.openstack.org<br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.org<br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
</font></tt></body></html>