[openstack-dev] [Heat] A concrete proposal for Heat Providers
thomas.spatzier at de.ibm.com
Mon Apr 29 09:12:37 UTC 2013
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
> 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
> > 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
> > the
> > > > stacks create? Or will it be possible to, for example, please
> > > > defined in one Stack on the same VM as MySQL defined in another
> > I
> > > > think it should be possible to have means for defining collocation
> > > > anti-collocation kinds of constraints.
> > >
> > > Heat as it exists now manages resources that map more or less
> > > 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
> > > 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
> > 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
> > fees. No question that such licensing models should be reconsidered
> > 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
> > (or other IaaS resource). Maybe Tomcat and MySQL are not the best
> > for this.
> > Anyway, my main point is that it should be possible to express such
> > 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
> our entire stack-scoped resource abstraction model.
> One thing you could do is pass Nova scheduler hints which enable some
> 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
> 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*
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.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev