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

Thomas Spatzier thomas.spatzier at de.ibm.com
Mon Apr 29 06:28:20 UTC 2013

Hi Zane,

I added a comment to a question you had inline below (cut out much of the
other details ..).


Zane Bitter <zbitter at redhat.com> wrote on 26.04.2013 19:41:25:

> From: Zane Bitter <zbitter at redhat.com>
> To: openstack-dev at lists.openstack.org,
> Date: 26.04.2013 19:42
> Subject: Re: [openstack-dev] [Heat] A concrete proposal for Heat
> On 26/04/13 09:39, Thomas Spatzier wrote:
> > So if I use multiple nested stacks with each one
> > deploying a couple of VMs, will I end up with the sum of VMs that all
> > stacks create? Or will it be possible to, for example, please Tomcat
> > defined in one Stack on the same VM as MySQL defined in another Stack?
> > think it should be possible to have means for defining collocation or
> > anti-collocation kinds of constraints.
> Heat as it exists now manages resources that map more or less directly
> to objects you can manipulate with the OpenStack APIs. Nova Servers,
> Swift Buckets, Quantum Networks, &c. The software that runs on an
> instance is not modelled in the template; it's just data that is passed
> to Nova when a server is created.
> I'm struggling to understand why you would want Tomcat from one stack
> co-located with MySQL from another stack (which implies a completely
> different application)... isn't the popularity of virtualisation
> entirely due to people _not_ wanting to have to do that? Can you
> elaborate on the use case a little more here?

So one reason why people might want to do it could be licenses. There are
OS licensing models where customers pay per OS node, so I've seen cases
where it was tried to collocate software pieces on a server to save license
fees. No question that such licensing models should be reconsidered (IMO),
but that's reality and I think it will be for some time.
Other reasons could be for optimization by placing things on the same VM
(or other IaaS resource). Maybe Tomcat and MySQL are not the best example
for this.
Anyway, my main point is that it should be possible to express such kinds
of collocation or anti-collocation constraints when composing nested

> cheers,
> Zane.
> _______________________________________________
> 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