Open Stack

Inline with Snipping

> > > > 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?
...

> Steven Hardy <shardy at redhat.com> wrote
> > 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.
...

> > > 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.
...
> > On Mon, Apr 29, 2013 at 08:34:15PM +1000, Angus Salkeld wrote:
> ...
> > > 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.

> Thomas Spatzier wrote:
> Yes, that's actually what I was looking for. Thanks for formulating more crisply,
> Angus :-) Being able to have re-usable parts defined I can use in many place but
> still have the ability to influence how they are placed in the infrastructure, e.g.
> not ending up with N virtula machines if I use N such parts. We call those parts
> NodeTypes in TOSCA.

> Steven Hardy <shardy at redhat.com> wrote on 29.04.2013 13:50:46:
> > 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 :)
> 
> Sounds good :-) Not yet sure how we best express this in the DSL, but working
> on it.

[Tripp, Travis S] 
I think this evolved to a very useful and real use case, but I actually would like to provide a little more to Thomas' original point.  I've been on a number of customer engagements where we are talking to them about setting up a private cloud and one of the big questions that the customer looks for is the ability to re-use resources for application deployments, because for some reason or another they don't want a VM per app. Usually it involves taking existing applications running in their legacy datacenter that they want to put into a new cloud paradigm. It would be great if all applications could be written for the cloud, but we've been told that X customer can't afford (time or money) to re-write their suite of 1000's of applications but IT wants to be more agile at providing infrastructure.  A very common reason has been to leverage a shared database that has DBA support for ongoing maintenance (backup, tuning, patching, etc). I can think of numerous ways to support this without Heat, but if nothing else, perhaps this would be to allow one stack to fetch meta-data from another stack so that it could configure itself using metadata from resources in another stack?