Open Stack

On 03/04/14 10:39, Ruslan Kamaldinov wrote:
> 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.
>
>
> 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.
>
> Again, this is only suggested starting point, something to begin with.
>
Thanks for bring this discussion back to solving specific problems. The
above database abstraction can be nicely represented using HOT
environments and provider resources [1].

Take the following template snippet:

resources:
  my_db:
    type: My::Database
    properties:
      # ...

  my_server
    type: OS::Nova::Server
    properties:
      # ... including a {get_attr: [my_db, connection_url]}

My::Database is a type defined in the environment which is included in
the stack-create call. Different environments can provide different
database implementations, for example:

resource_registry:
  "My::Database": path/to/trove_wrapper.yaml

resource_registry:
  "My::Database": path/to/nova_galera_ubercluster.yaml

resource_registry:
  "My::Database": path/to/postgresql.yaml

Each of these templates could be implemented to have the same parameters
and outputs so the template will work with any of these resource
provider templates.

One thing we could consider adding to HOT is allow the defining of a
type interface, and validating that a given template/resource implements
its declared interfaces. However the above example works just fine
without interfaces, and this duck-typing approach may provide a better
user experience anyway.

[1] http://docs.openstack.org/developer/heat/template_guide/environment.html