Open Stack

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.

-Angus

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