On 28 October 2013 16:23, Lakshminaraya Renganarayana <lren...@us.ibm.com> wrote: > Sorry, Re-posting this with [Heat] in the subject line, because many of us > have filters based on [Heat] in the subject line.
Thanks. BTW I found it a little weird that you replied as a new blueprint-scoped wiki page rather than an email, or as a discussion page on Steve's page. Anyhow. Your proposal for both delivering parameters to components and getting output from components suffer from namespace confusion. For instance, if I had a parameter called HOME, it would play havoc with the behaviour of shell scripts. Likewise if I had an output call params with your opt2 approach. As a general principle, separate namespaces are a good thing, so I propose that parameters to things that will run in-instance should be passed in in a dedicated namespace. This could be e.g. HEAT.param_name, or (better yet) not passed in at all, and instead permit the component to query the metadata for the parameters it needs from the machine metadata. This preserves separation of concerns: Heat doesn't need to know how to invoke the component, and the component has a well known interface for getting it's parameters. Handling of multi-invocation components would then become a scatter-gather approach: your WASP registration example would invoke that component once and it would find some N profiles to register when it queries it's metadata. (BTW, have a look at http://git.openstack.org/cgit/openstack/os-collect-config and http://git.openstack.org/cgit/openstack/os-apply-config for one implementation of this strategy - it's what we're using in TripleO). For outputs, I think a similar strategy - having a well defined means to upload metadata to heat - is all that's needed. -Rob > > Hello, > > A few us at IBM studied Steve Baker's proposal on HOT Software > Configuration. Overall the proposed constructs and syntax are great -- we > really like the clean syntax and concise specification of components. We > would like to propose a few minor extensions that help with better > expression of dependencies among components and resources, and in-turn > enable cross-vm coordination. We have captured our thoughts on this on the > following Wiki page -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev