<html><body>
<p><font size="2" face="sans-serif">Hi Stan,</font><br>
<br>
<font size="2" face="sans-serif">Thanks for the comments. As you have observed the prototype that I have built is tied to Chef. I just wanted to describe that here for reference and not as a proposal for the general implementation. What I would like to work on is a more general solution that is agnostic to (or works with any) underlying CM tool (such as chfe, puppet, saltstack, murano, etc.). </font><br>
<br>
<font size="2" face="sans-serif">Regarding identifying reads/writes: I was thinking that we could come up with a general syntax + semantics of explicitly defining the reads/writes of Heat components. I think we can extend Steve Baker's recent proposal, to include the inputs/outputs in software component definitions. Your experience with the Unified Agent would be valuable for this. I would be happy to collaborate with you!</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">Stan Lagun <slagun@mirantis.com> wrote on 10/21/2013 10:03:58 AM:<br>
<br>
> From: Stan Lagun <slagun@mirantis.com></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/21/2013 10:18 AM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] [Heat] A prototype for cross-vm <br>
> synchronization and communication</font></tt><br>
<tt><font size="2">> <br>
> Hi Lakshminarayanan,<br>
</font></tt><br>
<tt><font size="2">> Seems like a solid plan. <br>
> I'm probably wrong here but ain't this too tied to chef? I believe <br>
> the solution should equally be suitable for chef, puppet, SaltStack,<br>
> Murano, or maybe all I need is just a plain bash script execution. <br>
> It may be difficult to intercept script reads the way it is possible<br>
> with chef's node[][]. In Murano we has a generic agent that could <br>
> integrate all such deployment platforms using common syntax. Agent <br>
> specification can be found here: <a href="https://wiki.openstack.org/wiki/">https://wiki.openstack.org/wiki/</a><br>
> Murano/UnifiedAgent and it can be helpful or at least can be a <br>
> source for design ideas.<br>
</font></tt><br>
<tt><font size="2">> I'm very positive on adoption on such solution to Heat. There would <br>
> be a significant amount of work to abstract all underlying <br>
> technologies (chef, Zookeper etc) so that they become pluggable and <br>
> replaceable without introducing hard-coded dependencies for the Heat<br>
> and bringing everything to production quality level. We could <br>
> collaborate on bringing such solution to the Heat if it would be <br>
> accepted by Heat's core team and community</font></tt><br>
<tt><font size="2">> <br>
> <br>
</font></tt><br>
<tt><font size="2">> On Fri, Oct 18, 2013 at 10:45 PM, Lakshminaraya Renganarayana <<br>
> lrengan@us.ibm.com> wrote:</font></tt><br>
<tt><font size="2">> 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</font></tt><br>
<tt><font size="2">> <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>
</font></tt><br>
<tt><font size="2">> <br>
> <br>
> <br>
> -- </font></tt><br>
<tt><font size="2">> Sincerely yours<br>
> Stanislav (Stan) Lagun<br>
> Senior Developer<br>
> Mirantis<br>
> 35b/3, Vorontsovskaya St.<br>
> Moscow, Russia<br>
> Skype: stanlagun<br>
> www.mirantis.com<br>
> slagun@mirantis.com_______________________________________________<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>