[openstack-dev] [Heat] A concrete proposal for Heat Providers
thomas.spatzier at de.ibm.com
Mon Apr 29 12:08:24 UTC 2013
Steven Hardy <shardy at redhat.com> wrote on 29.04.2013 13:50:46:
> From: Steven Hardy <shardy at redhat.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 29.04.2013 13:51
> Subject: Re: [openstack-dev] [Heat] A concrete proposal for Heat
> On Mon, Apr 29, 2013 at 08:34:15PM +1000, Angus Salkeld wrote:
> > On 29/04/13 09:30 +0100, Steven Hardy wrote:
> > This could be like a AutoScaling LoadConfig, basically a chunk of
> > config that gets passed down to a cfn config group. The idea is then
> > to be able to share that config snippet by having it in another file
> > (nested stack template, with only one Config resource) - not a big
> > deal IMO. What would be cool is if you could then pass more than
> > one to the Server.
> > Why?
> > Just from a code reuse point of view. We have a bunch of WordPress
> > templates right? How many times do we setup mysql/wordpress? - that is
> > Instead we have a mysql-config.template and a
> > wordpress-config.template. Then in the
> > Wordpress_Single_Instance.template we include both, and in the
> > 2_Instance we include one each. This then makes it easier to share
> > configurations eventhough the stacks might be a bit different.
Yes, that's actually what I was looking for. Thanks for formulating more
crisply, Angus :-)
Being able to have re-usable parts defined I can use in many place but
still have the ability to influence how they are placed in the
infrastructure, e.g. not ending up with N virtula machines if I use N such
parts. We call those parts NodeTypes in TOSCA.
> Ok, this makes much more sense to me - maybe I misunderstood, but I
> Thomas was talking about a much more complex relationship, e.g an
> inheritance/aggregration type of design where application-related
> objects in different stacks refer to one instance resource.
> Passing a Ref to a config-blob resource of some sort, as a
> parameter/property sounds much simpler, so +1 from me :)
Sounds good :-) Not yet sure how we best express this in the DSL, but
working on it.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev