<html><body>
<p><tt><font size="2">Robert Collins <robertc@robertcollins.net> wrote on 10/28/2013 02:47:53 PM:<br>
<br>
> BTW I found it a little weird that you replied as a new<br>
> blueprint-scoped wiki page rather than an email, or as a discussion<br>
> page on Steve's page.</font></tt><br>
<br>
<tt><font size="2">It was a bit too long to directly post as an email text on the mailing </font></tt><br>
<tt><font size="2">list. Also, posting it as a wiki page allowed me to format it better. </font></tt><br>
<tt><font size="2">I did not know what is preferred and hence chose the separate page. </font></tt><br>
<tt><font size="2">I am perfectly fine with posting as a discussion on Steve's page. </font></tt><br>
<tt><font size="2">Let me know.</font></tt><br>
<br>
<tt><font size="2"><br>
> Your proposal for both delivering parameters to components and getting<br>
> output from components suffer from namespace confusion. For instance,<br>
> if I had a parameter called HOME, it would play havoc with the<br>
> behaviour of shell scripts. Likewise if I had an output call params<br>
> with your opt2 approach.<br>
> <br>
> As a general principle, separate namespaces are a good thing, so I<br>
> propose that parameters to things that will run in-instance should be<br>
> passed in in a dedicated namespace.</font></tt><br>
<br>
<tt><font size="2">I fully agree with you -- a separate dedicated namespace is best.</font></tt><br>
<tt><font size="2"><br>
> <br>
> This could be e.g. HEAT.param_name, or (better yet) not passed in at<br>
> all, and instead permit the component to query the metadata for the<br>
> parameters it needs from the machine metadata. This preserves<br>
> separation of concerns: Heat doesn't need to know how to invoke the<br>
> component, and the component has a well known interface for getting<br>
> it's parameters. Handling of multi-invocation components would then<br>
> become a scatter-gather approach: your WASP registration example would<br>
> invoke that component once and it would find some N profiles to<br>
> register when it queries it's metadata.<br>
</font></tt><br>
<tt><font size="2">Agree with you on the use of metadata service -- we also thought of the</font></tt><br>
<tt><font size="2">inputs and outputs of component invocations being stored and retrieved </font></tt><br>
<tt><font size="2">by the component providers from the Heat metadata service.</font></tt><br>
<br>
<tt><font size="2">> <br>
> (BTW, have a look at<br>
> <a href="http://git.openstack.org/cgit/openstack/os-collect-config">http://git.openstack.org/cgit/openstack/os-collect-config</a> and<br>
> <a href="http://git.openstack.org/cgit/openstack/os-apply-config">http://git.openstack.org/cgit/openstack/os-apply-config</a> for one<br>
> implementation of this strategy - it's what we're using in TripleO).</font></tt><br>
<br>
<tt><font size="2">Thanks for the pointers. I will look at them.</font></tt><br>
<tt><font size="2"><br>
> <br>
> For outputs, I think a similar strategy - having a well defined means<br>
> to upload metadata to heat - is all that's needed.<br>
</font></tt><br>
<tt><font size="2">Agreed.</font></tt><br>
<br>
<br>
<tt><font size="2">> -Rob<br>
> <br>
> ><br>
> > Hello,<br>
> ><br>
> > A few us at IBM studied Steve Baker's proposal on HOT Software<br>
> > Configuration. Overall the proposed constructs and syntax are great -- we<br>
> > really like the clean syntax and concise specification of components. We<br>
> > would like to propose a few minor extensions that help with better<br>
> > expression of dependencies among components and resources, and in-turn<br>
> > enable cross-vm coordination. We have captured our thoughts on this on the<br>
> > following Wiki page<br>
> <br>
> <br>
> <br>
> <br>
> -- <br>
> Robert Collins <rbtcollins@hp.com><br>
> Distinguished Technologist<br>
> HP Converged Cloud<br>
> <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>
> <br>
</font></tt></body></html>