Open Stack

On 05/01/2013 08:27 PM, Tripp, Travis S wrote:
> 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?

That makes sense as a use case to me. I wonder though if perhaps the
schema on the shared database is simply something that wants a custom
database resource written for it, so that a self-contained heat stack
can use it. (I know you're giving an example for the general case and
I'm solving the specific case- but I'm wondering if it could be a matter
of framing and approach?)

Monty