Open Stack

Excerpts from Ruslan Kamaldinov's message of 2014-04-02 14:39:17 -0700:
> This is a continuation of the "MuranoPL questions" thread.
> 
> As a result of ongoing discussions, we figured out that definition of layers
> which each project operates on and has responsibility for is not yet agreed
> and discussed between projects and teams (Heat, Murano, Solum (in
> alphabetical order)).
> 
> Our suggestion and expectation from this working group is to have such
> a definition of layers, agreement on it and an approach of reaching it.
> 
> As a starting point, we suggest the following:
> 
> There are three layers of responsibility:
> 1. Resources of the cloud
> 2. Applications of the cloud
> 3. Layers specific for Murano and Solum (to be further discussed and
>    clarified, for this discussion it's out of scope)
> 
> Layer 1 is obviously covered by Heat.
> 
> Most of the disagreement is around layer 2. Our suggestion is to figure out
> the way where we can have common engine, DSL and approach to apps description.
> For this we'll take HOT and TOSCA as a basis and will work on addition of
> functionality missing from Murano and Solum point of view.
> 
> We'll be happy if existing Heat team continue working on it, having the full
> control of the project, provided that we agree on functionality missing there
> from Murano and Solum point of view and addition of this functionality in a
> systematic way.
> 
> Let me outline the main concern in regards to HOT from Murano perspective.
> Others concerns could be figured out later. The typical use case for Murano is
> the following:
> Application writer sets a requirement for her application to use RDBMS
> assuming that it can be MySQL, PostgreSQL or MSSQL. HOT engine should be able
> to understand such requirements and be able to satisfy them by instantiating
> instances with DB. End user should be able to control which particular type of
> DB should be used. This is quite similar to abstract requirements described in
> TOSCA. As Heat wants to cover TOSCA format too this Murano requirement is
> pretty well aligned with what HOT\TOSCA can provide.
> 

IMO that is too high level for Heat. Heat speaks to APIs. It has a few of
its own that are low-level generic facilities, or high level left-over's
from the early days that all have better native replacements.

If there is no API to get a PostgreSQL or MSSQL database, then there is
no PostgreSQL or MSSQL database for Heat. What there may be is an API to
get a server and configure it. And Providers can handle the abstraction.
However,Heat isn't specifically going to ever know how one resource is
going to depend on another. It is just going to obey your commands to
create them and share configuration between them.

Meanwhile, Trove is the place to drive database as a service features.

> 
> Hopefully this functionality can be introduced into HOT. Solum and Murano will
> leverage it by using some common API, and implementing layer 3 as thin as
> possible.
> 

I'm not really sure what is missing from HOT that you need. With
providers you should be able to achieve anything you need around
portability.