<html><body>
<p><tt><font size="2">Zane, thanks very much for the detailed feedback. I have added my comments inline.</font></tt><br>
<br>
<tt><font size="2">Zane Bitter <zbitter@redhat.com> wrote on 10/29/2013 08:46:21 AM:<br>
... <br>
> As brief feedback on these suggestions:<br>
> E1: Probably +1 for inputs, but tentative -1 for attributes. I'm not <br>
> sure we can check anything useful with that other than internal <br>
> consistency of the template. </font></tt><br>
<br>
<tt><font size="2">The explicit specification of the attributes (or outputs) is aimed primarily</font></tt><br>
<tt><font size="2">at providing a name for the output so that they can be referred to in component</font></tt><br>
<tt><font size="2">invocations and also by software config providers (Chef or Puppet, etc.) to </font></tt><br>
<tt><font size="2">access them. The use of the attributes to check or validate is only a secondary</font></tt><br>
<tt><font size="2">aim and this could just be a consistency check with name matching. If we had</font></tt><br>
<tt><font size="2">more information such as types, constraints, about these attributes </font></tt><br>
<tt><font size="2">(similar to inputs of a template) we can validate more. But this is not </font></tt><br>
<tt><font size="2">the primary goal.</font></tt><br>
<br>
<tt><font size="2">>I'd like to see some more detail about how <br>
> inputs/outputs would be exposed in the configuration management systems <br>
> - or, more specifically, how the user can extend this to arbitrary <br>
> configuration management systems.</font></tt><br>
<br>
<tt><font size="2">The way inputs/outputs are exposed in a CM system </font></tt><br>
<tt><font size="2">would depend on its conventions. In our use with Chef, we expose these</font></tt><br>
<tt><font size="2">inputs and outputs as a Chef's node attributes, i.e., via the node[][]</font></tt><br>
<tt><font size="2">hash. I could imagine a similar scheme for Puppet. For a shell type of</font></tt><br>
<tt><font size="2">CM provider the inputs/outputs can be exposed as Shell environment </font></tt><br>
<tt><font size="2">variables. To avoid name conflicts, these inputs/outputs can be prefixed</font></tt><br>
<tt><font size="2">by a namespace, say Heat.</font></tt><br>
<br>
<tt><font size="2"><br>
> <br>
> E2: +1 for Opt1<br>
> -1 for Opt2 (mixing namespaces is bad)<br>
> -1 for Opt3<br>
</font></tt><br>
<tt><font size="2">Agreed -- we also prefer Opt1!</font></tt><br>
<br>
<tt><font size="2">> <br>
> E3: Sounds like a real issue (also, the solution for E2 has to take this <br>
> into account too); not sure about the implementation. </font></tt><br>
<br>
<tt><font size="2">Yes, agreed -- E2 has to understand which output from which invocation of </font></tt><br>
<tt><font size="2">a component is being used or referred to. With invocation_id's it should</font></tt><br>
<tt><font size="2">be possible to uniquely identify the component invocation.</font></tt><br>
<br>
<br>
<tt><font size="2">In this method <br>
> (i.e. option (2) above) shouldn't we be building the dependency graph in <br>
> Heat rather than running through them sequentially as specified by the <br>
> user? In that case, we should use a dictionary not a list:<br>
> <br>
> app_server:<br>
> type: OS::Nova::Server<br>
> properties:<br>
> components:<br>
> install_user_profile:<br>
> definition: InstallWasProfile<br>
> params:<br>
> user_id<br>
> install_admin_profile:<br>
> definition: InstallWasProfile<br>
> params:<br>
> admin_id</font></tt><br>
<br>
<tt><font size="2">I missed this implication of using a list! You are right, it should be </font></tt><br>
<tt><font size="2">a dictionary and Heat would be building the dependence graph. </font></tt><br>
<br>
<tt><font size="2"><br>
> E5: +1 but a question on where this is specified. In the component <br>
> definition itself, or in the particular invocation of it on a server? <br>
> Seems like it would have to be the latter.<br>
</font></tt><br>
<tt><font size="2">Good point. I think it could be specified on both places. It definitely </font></tt><br>
<tt><font size="2">could be specified on a particular invocation. I am not fully sure on this, </font></tt><br>
<tt><font size="2">but one can also imagine cases where a cross-component </font></tt><br>
<tt><font size="2">dependency is true for all invocations of a component, and hence might </font></tt><br>
<tt><font size="2">be specified as a part of the component definition as a dependency between</font></tt><br>
<tt><font size="2">two component types.</font></tt><br>
<br>
<tt><font size="2">Thanks,</font></tt><br>
<tt><font size="2">LN</font></tt><br>
<br>
<br>
<br>
</body></html>