Open Stack

On 28 October 2013 16:23, Lakshminaraya Renganarayana
<lrengan at 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud