Open Stack

Excerpts from Alexander Kuznetsov's message of 2013-10-31 10:51:54 -0700:
> Hi Heat, Savanna and Trove teams,
> 
> All this projects have common part related to software configuration
> management.  For creation,  an environment  user should specify a hardware
> parameter for vms:  choose flavor, decide use cinder or not, configure
> networks for virtual machines, choose topology for hole deployment. Next
> step is linking of software parameters with hardware specification. From
> the end user point of view, existence of three different places and three
> different ways (HEAT Hot DSL, Trove clustering API and Savanna Hadoop
> templates) for software configuration is not convenient, especially if user
> want to create an environment simultaneously involving components from
> Savanna, Heat and Trove.
> 

I'm having a hard time extracting the problem statement. I _think_ that
the problem is:

As a user I want to tune my software for my available hardware.

So what you're saying is, if you select a flavor that has 4GB of RAM
for your application, you want to also tell your application that it
can use 3GB of RAM for an in-memory cache. Likewise, if one has asked
Trove for an 8GB flavor, they will want to tell it to use 6.5GB of RAM
for InnoDB buffer cache.

What you'd like to see is one general pattern to express these types
of things?

> I can suggest two approaches to overcome this situations:
> 
> Common library in oslo. This approach allows a deep domain specific
> customization. The user will still have 3 places with same UI where user
> should perform configuration actions.
> 
> Heat or some other component for software configuration management. This
> approach is the best for end users. In feature possible will be some
> limitation on deep domain specific customization for configuration
> management.

Can you maybe be more concrete with your proposed solutions? The lack
of a clear problem statement combined with these vague solutions has
thoroughly confused me.