Open Stack

Hi Steven,

Steven Hardy <shardy at redhat.com> wrote on 29.04.2013 10:30:56:

> From: Steven Hardy <shardy at redhat.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 29.04.2013 10:31
> Subject: Re: [openstack-dev] [Heat] A concrete proposal for Heat
Providers
>
> 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.

You could be right here, but I would probably not make such a hard
statement that it should not be implemented in Heat (at all). There have
been other discussions on whether Heat is pure infrastructure or also moves
into higher layers of orchestration and who knows where the journey goes.
I am also not saying we have to do it from the beginning, but want to make
sure we do not cut out things in the DSL definition that could be important
in a future step.

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