Open Stack

Robert Collins <robertc at robertcollins.net> wrote on 10/28/2013 02:47:53 PM:

> 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.

It was a bit too long to directly post as an email text on the mailing
list. Also, posting it as a wiki page allowed me to format it better.
I did not know what is preferred and hence chose the separate page.
I am perfectly fine with posting as a discussion on Steve's page.
Let me know.


> 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.

I fully agree with you -- a separate dedicated namespace is best.

>
> 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.

Agree with you on the use of metadata service -- we also thought of the
inputs and outputs of component invocations being stored and retrieved
by the component providers from the Heat metadata service.

>
> (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).

Thanks for the pointers. I will look at them.

>
> For outputs, I think a similar strategy - having a well defined means
> to upload metadata to heat - is all that's needed.

Agreed.


> -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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131028/c613d7ba/attachment.html>