Open Stack

Excerpts from Zane Bitter's message of 2013-04-26 10:41:25 -0700:
> 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 the
> > 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? I
> > 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?
> 

If we have a flavor that fits every use case, then yes, combining work
loads into VMs is somewhat counter-productive.

However, consider the baremetal use case, where we may have a rack of 40
identical servers, all powerful enough to handle the most demanding of
our applications, but also far too powerful to handle one of them. I am
actually running into this right now while trying to write CFN templates
for OpenStack on OpenStack.

The Heat API services, for instance, are very lightweight. But keystone
can be very taxing on memory and CPU. I'd like to be able to group all
of the light weight services together inside one "server". At the same
time, I may want to be able to split them out.

This applies to the virt use case as well. As has already been stated,
there are optimization reasons to run two apps on the same VM. There
is also a cost issue. A smaller testing cloud may not be able to give
developers all of the VMs that production requires, and so people will
want to co-locate things together.

So I think the message here is that there are two concepts that should be
expressable separately:

* I have app X, which needs informational bits a,b, and c, from other
parts of my stack.

* I want to run app X on a compute resource with properties y and z.

So, it would be useful if the DSL is able to express things things
separately.

As another data point, the juju project still struggles with this concept,
and it has been a real sticking point for a lot of users to not be able
to assemble their apps separate from their resources.