[openstack-dev] [Heat] A concrete proposal for Heat Providers

Thomas Spatzier thomas.spatzier at de.ibm.com
Mon Apr 29 14:17:46 UTC 2013

Zane Bitter <zbitter at redhat.com> wrote on 29.04.2013 15:49:28:

> From: Zane Bitter <zbitter at redhat.com>
> To: openstack-dev at lists.openstack.org,
> Date: 29.04.2013 15:50
> Subject: Re: [openstack-dev] [Heat] A concrete proposal for Heat
> On 29/04/13 12:34, Angus Salkeld wrote:
> > On 29/04/13 09:30 +0100, Steven Hardy wrote:
> >> Your example, to me, seems basically a PaaSish pattern, where people
> >> applications to be deployed onto a shared OS platform.  This makes it
> >> pattern we should enable (layered on top of Heat), but not *implement*
> >> IMO.
> >
> > 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
> > dumb.
> > 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.
> Isn't this what Puppet/Chef do already?

On a per node base I agree, and Chef/Puppet could be the implementation
that does the stuff on the VMs. However, when you look at multi-machine
deployments it gets complicated at some point when to try to pass
parameters back and forth. So this is when an orchestration engine would be
become relevant.

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list