<div dir="ltr"><div><div>Hi Lakshminarayanan,<br><br></div>Seems like a solid plan. <br>I'm probably wrong here but ain't this too tied to chef? I believe the solution should equally be suitable for chef, puppet, SaltStack, Murano, or maybe all I need is just a plain bash script execution. It may be difficult to intercept script reads the way it is possible with chef's node[][]. In Murano we has a generic agent that could integrate all such deployment platforms using common syntax. Agent specification can be found here: <a href="https://wiki.openstack.org/wiki/Murano/UnifiedAgent">https://wiki.openstack.org/wiki/Murano/UnifiedAgent</a> and it can be helpful or at least can be a source for design ideas.<br>
<br></div><div>I'm very positive on adoption on such solution to Heat. There would be a significant amount of work to abstract all underlying technologies (chef, Zookeper etc) so that they become pluggable and replaceable without introducing hard-coded dependencies for the Heat and bringing everything to production quality level. We could collaborate on bringing such solution to the Heat if it would be accepted by Heat's core team and community<br>
</div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 18, 2013 at 10:45 PM, 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><font face="sans-serif">Hi,</font><br>
<br>
<font face="sans-serif">In the last Openstack Heat meeting there was good interest in proposals for cross-vm synchronization and communication and I had mentioned the prototype I have built. I had also promised that I will post an outline of the prototype ... Here it is. I might have missed some details, please feel free to ask / comment and I would be happy to explain more.</font><br>
<font face="sans-serif">---</font><br>
<font face="sans-serif">Goal of the prototype: Enable cross-vm synchronization and communication using high-level declarative description (no wait-conditions) Use chef as the CM tool.</font><br>
<br>
<font face="sans-serif">Design rationale / choices of the prototype (note that these were made just for the prototype and I am not proposing them to be the choices for Heat/HOT):</font><br>
<br>
<font face="sans-serif">D1: No new construct in Heat template</font><br>
<font face="sans-serif"> => use metadata sections</font><br>
<font face="sans-serif">D2: No extensions to core Heat engine</font><br>
<font face="sans-serif"> => use a pre-processor that will produce a Heat template that the standard Heat engine can consume</font><br>
<font face="sans-serif">D3: Do not require chef recipes to be modified</font><br>
<font face="sans-serif"> => use a convention of accessing inputs/outputs from chef node[][]</font><br>
<font face="sans-serif"> => use ruby meta-programming to intercept reads/writes to node[][] forward values</font><br>
<font face="sans-serif">D4: Use a standard distributed coordinator (don't reinvent)</font><br>
<font face="sans-serif"> => use zookeeper as a coordinator and as a global data space for communciation</font><br>
<br>
<font face="sans-serif">Overall, the flow is the following:</font><br>
<font face="sans-serif">1. User specifies a Heat template with details about software config and dependences in the metadata section of resources (see step S1 below).</font><br>
<font face="sans-serif">2. A pre-processor consumes this augmented heat template and produces another heat template with user-data sections with cloud-init scripts and also sets up a zookeeper instance with enough information to coordinate between the resources at runtime to realize the dependences and synchronization (see step S2)</font><br>
<font face="sans-serif">3. The generated heat template is fed into standard heat engine to deploy. After the VMs are created the cloud-init script kicks in. The cloud init script installs chef solo and then starts the execution of the roles specified in the metadata section. During this execution of the recipes the coordination is realized (see steps S2 and S3 below).</font><br>
<br>
<font face="sans-serif">Implementation scheme:</font><br>
<font face="sans-serif">S1. Use metadata section of each resource to describe (see attached example)</font><br>
<font face="sans-serif"> - a list of roles</font><br>
<font face="sans-serif"> - inputs to and outputs from each role and their mapping to resource attrs (any attr)</font><br>
<font face="sans-serif"> - convention: these inputs/outputs will be through chef node attrs node[][]</font><br>
<br>
<font face="sans-serif">S2. Dependence analysis and cloud init script generation</font><br>
<font face="sans-serif"> </font><br>
<font face="sans-serif"> Dependence analysis:</font><br>
<font face="sans-serif"> - resolve every reference that can be statically resolved using Heat's fucntions (this step just uses Heat's current dependence analysis -- Thanks to Zane Bitter for helping me understand this)</font><br>
<font face="sans-serif"> - flag all unresolved references as values resolved at run-time at communicated via the coordinator</font><br>
<br>
<font face="sans-serif"> Use cloud-init in user-data sections:</font><br>
<font face="sans-serif"> - automatically generate a script that would bootstrap chef and will run the roles/recipes in the order specified in the metadata section</font><br>
<font face="sans-serif"> - generate dependence info for zookeeper to coordinate at runtime</font><br>
<br>
<font face="sans-serif">S3. Coordinate synchronization and communication at run-time</font><br>
<font face="sans-serif"> - intercept reads and writes to node[][]</font><br>
<font face="sans-serif"> - if it is a remote read, get it from Zookeeper</font><br>
<font face="sans-serif"> - execution will block till the value is available</font><br>
<font face="sans-serif"> - if write is for a value required by a remote resource, write the value to Zookeeper</font><br>
<br>
<font face="sans-serif">The prototype is implemented in Python and Ruby is used for chef interception. </font><br>
<br>
<font face="sans-serif">There are alternatives for many of the choices I have made for the prototype:</font><br>
<font face="sans-serif"> - zookeeper can be replaced with any other service that provides a data space and distributed coordination</font><br>
<font face="sans-serif"> - chef can be replaced by any other CM tool (a little bit of design / convention needed for other CM tools because of the interception used in the prototype to catch reads/writes to node[][])</font><br>
<font face="sans-serif"> - the whole dependence analysis can be integrated into the Heat's dependence analyzer</font><br>
<font face="sans-serif"> - the component construct proposed recently (by Steve Baker) for HOT/Heat can be used to specify much of what is specified using the metadata sections in this prototype.</font><br>
<br>
<font face="sans-serif">I am interested in using my experience with this prototype to contribute to HOT/Heat's cross-vm synchronization and communication design and code. I look forward to your comments.</font><br>
<br>
<font face="sans-serif">Thanks,</font><br>
<font face="sans-serif">LN</font><br>
</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"><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>