<html><body>
<p><font size="2" face="sans-serif">Hi Angus,</font><br>
<br>
<font size="2" face="sans-serif">Thanks for detailed reply. I have a few comments that I have written below in the context. </font><br>
<br>
<br>
<tt><font size="2">Angus Salkeld <asalkeld@redhat.com> wrote on 10/13/2013 06:40:01 PM:<br>
<br>
> ><br>
> >- INPUTS: all the attributes that are consumed/used/read by that resource<br>
> >(currently, we have Ref, GetAttrs that can give this implicitly)<br>
> ><br>
> >- OUTPUTS: all the attributes that are produced/written by that resource (I<br>
> >do not know if this write-set is currently well-defined for a resource. I<br>
> >think some of them are implicitly defined by Heat on particular resource<br>
> >types.)<br>
> ><br>
> >- Global name-space and data-space : all the values produced and consumed<br>
> >(INPUTS/OUTPUTS) are described using a names that are fully qualified<br>
> >(XXX.stack_name.resource_name.property_name). The data values associated<br>
> >with these names are stored in a global data-space. Reads are blocking,<br>
> >i.e., reading a value will block the execution resource/thread until the<br>
> >value is available. Writes are non-blocking, i.e., any thread can write a<br>
> >value and the write will succeed immediately.<br>
> <br>
> I don't believe this would give us any new behaviour.</font></tt><br>
<br>
<tt><font size="2">I believe that in today's Heat, wait-conditions and signals are the only </font></tt><br>
<tt><font size="2">mechanism for synchronization during software configuration. The proposed</font></tt><br>
<tt><font size="2">mechanism would provide a higher level synchronization based on blocking-reads.</font></tt><br>
<tt><font size="2">For example, if one is using Chef for software configuration, then the</font></tt><br>
<tt><font size="2">recipes can use the proposed mechanism to wait for the all the node[][] attributes</font></tt><br>
<tt><font size="2">they require before starting the recipe execution. And, Heat can actually</font></tt><br>
<tt><font size="2">analyze and reason about deadlock properties of such a synchronization. On </font></tt><br>
<tt><font size="2">the other hand, if the recipe were using wait-conditions how would Heat </font></tt><br>
<tt><font size="2">reason about deadlock properties of it?</font></tt><br>
<tt><font size="2"><br>
> <br>
> ><br>
> >The ability to define resources at arbitrary levels of granularity together<br>
> >with the explicit specification of INPUTS/OUTPUTS allows us to reap the<br>
> >benefits G1 and G2 outlined above. Note that the ability to reason about<br>
> >the inputs/outputs of each resource and the induced dependencies will also<br>
> >allow Heat to detect dead-locks via dependence cycles (benefit G3). This is<br>
> >already done today in Heat for Refs, GetAttr on base-resources, but the<br>
> >proposal is to extend the same to arbitrary attributes for any resource.<br>
> <br>
> How are TemplateResources and NestedStacks any different? To my<br>
> knowledge this is aleady the case.<br>
> <br>
> >The blocking-read and non-blocking writes further structures the<br>
> >specification to avoid deadlocks and race conditions (benefit G3).<br>
> <br>
> Have you experienced deadlocks with heat? I have never seen this...</font></tt><br>
<br>
<tt><font size="2">Heat as it is today does not tackle the problem of synchronization during</font></tt><br>
<tt><font size="2">software configuration and hence the problems I see cannot be attributed to</font></tt><br>
<tt><font size="2">Heat and can only be attributed to the scripts / recipes that do the </font></tt><br>
<tt><font size="2">software configuration. However, if we envision Heat to provide some</font></tt><br>
<tt><font size="2">support for software configuration I can easily imagine cases where </font></tt><br>
<tt><font size="2">it is impossible for Heat to analyze/reason with wait-conditions and hence </font></tt><br>
<tt><font size="2">leading to deadlocks. Wait-conditions and signals are equal to </font></tt><br>
<tt><font size="2">Timed-Semaphores in their power and expressivity and these are </font></tt><br>
<tt><font size="2">known for their problems with deadlocks. </font></tt><br>
<br>
<tt><font size="2">> <br>
> To me what is missing to better support complex software configuration<br>
> is :<br>
> - better integrating with existing configuration tools (puppet, chef,<br>
> salt, ansible, etc). (resource types)<br>
</font></tt><br>
<tt><font size="2">One question is, whether in this integration the synchronization is completely</font></tt><br>
<tt><font size="2">left to the configuration tools or Heat would be involved in it. If it is </font></tt><br>
<tt><font size="2">left to configuration tools, say chef, then the question is how does the</font></tt><br>
<tt><font size="2">iterative convergence style execution of chef interfere with the schedule</font></tt><br>
<tt><font size="2">order that Heat determines for a template. On the other hand, if Heat provides</font></tt><br>
<tt><font size="2">the mechanism for synchronization, then the question is whether wait-conditions</font></tt><br>
<tt><font size="2">and signals are the right abstractions for them. What are your thoughts on this?</font></tt><br>
<br>
<tt><font size="2">Thanks,</font></tt><br>
<tt><font size="2">LN</font></tt><br>
<br>
</body></html>