Open Stack

On Mon, Apr 29, 2013 at 08:34:15PM +1000, Angus Salkeld wrote:
> On 29/04/13 09:30 +0100, Steven Hardy wrote:
> >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.
> 
> 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.

Ok, this makes much more sense to me - maybe I misunderstood, but I thought
Thomas was talking about a much more complex relationship, e.g an 
inheritance/aggregration type of design where application-related resource
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 :)

Steve