<html><body>
<p><font size="2" face="sans-serif">Just wanted to add a couple of clarifications:</font><br>
<br>
<font size="2" face="sans-serif">1. the cross-vm dependences are captured via the read/writes of attributes in resources and in software components (described in metadata sections). </font><br>
<br>
<font size="2" face="sans-serif">2. these dependences are then realized via blocking-reads and writes to zookeeper, which realizes the cross-vm synchronization and communication of values between the resources.</font><br>
<br>
<font size="2" face="sans-serif">Thanks,</font><br>
<font size="2" face="sans-serif">LN</font><br>
<br>
<br>
<tt><font size="2">Lakshminaraya Renganarayana/Watson/IBM@IBMUS wrote on 10/18/2013 02:45:01 PM:<br>
<br>
> From: Lakshminaraya Renganarayana/Watson/IBM@IBMUS</font></tt><br>
<tt><font size="2">> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org></font></tt><br>
<tt><font size="2">> Date: 10/18/2013 02:48 PM</font></tt><br>
<tt><font size="2">> Subject: [openstack-dev] [Heat] A prototype for cross-vm <br>
> synchronization and communication</font></tt><br>
<tt><font size="2">> <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 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 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 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>
> 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 the prototype:<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>
</font></tt></body></html>