Open Stack

On Mon, Apr 29, 2013 at 08:28:20AM +0200, Thomas Spatzier wrote:
> Hi Zane,
> 
> I added a comment to a question you had inline below (cut out much of the
> other details ..).
> 
> Regards,
> Thomas
> 
> 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
> Providers
> >
> > 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?
> >
> 
> 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
> stacks.

This example still doesn't make sense to me - if you want to express this
(IMO wrong) application deployment pattern, then you need to define the
application configuration in the same stack, it doesn't make sense to
somehow allow "sharing" instance resources between stacks.  It also breaks
our entire stack-scoped resource abstraction model.

One thing you could do is pass Nova scheduler hints which enable some sort
of co-location or anti-colocation, e.g required for performance reasons,
but this would be instances (not applications) located based on some
Nova scheduler filter which defines affinity or anti affinity (we already
support scheduler hints, but also ref the nova group scheduling discussions
related to this)

Your example, to me, seems basically a PaaSish pattern, where people want
applications to be deployed onto a shared OS platform.  This makes it a
pattern we should enable (layered on top of Heat), but not *implement* IMO.

Steve