<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/04/14 13:04, Georgy
Okrokvertskhov wrote:<br>
</div>
<blockquote
cite="mid:CAG_6_omGVxuw_nC7nFnpWkZNivnbJ=s-gUd9CcOOr_Q7_pAa8w@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Steve,
<div><br>
</div>
<div>I think this is exactly the place where we have a boundary
between Murano catalog and HOT.</div>
<div><br>
</div>
<div>In your example one can use abstract resource type and
specify a correct implementation via environment file. This is
how it will be done on the final stage in Murano too.</div>
<div><br>
</div>
<div>Murano will solve another issue. In your example user
should know what template to use as a provider template. In
Murano this will be done in the following way:</div>
<div>1) User selects an app which requires a DB</div>
<div>2) Murano sees this requirement for DB and do a search in
the app catalog to find all apps which expose this
functionality. Murano uses app package definitions for that.</div>
<div>3) User select in UI specific DB implementation he wants to
use.</div>
<div><br>
</div>
<div>As you see, in Murano case user has no preliminary
knowledge of available apps\templates and it uses catalog to
find it. A search criteria can be quite complex with using
different application attribute. If we think about moving
application definition to HOT format it should provide all
necessary information for catalog.</div>
<div><br>
</div>
<div>In order to search apps in catalog which uses HOT format we
need something like that:</div>
<div><br>
</div>
<div>One needs to define abstract resource like</div>
<div>OS:HOT:DataBase</div>
<div><br>
</div>
<div>
Than in each DB implementation of DB resource one has to
somehow refer this abstract resource as a parent like</div>
<div><br>
</div>
<div>Resource OS:HOT:MySQLDB</div>
<div> Parent: OS:HOT:DataBase</div>
<div><br>
</div>
<div>
Then catalog part can use this information and build a list of
all apps\HOTs with resources with parents OS:HOT:DataBase</div>
<div><br>
</div>
<div>That is what we are looking for. As you see, in this
example I am not talking about version and other attributes
which might be required for catalog.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
This sounds like a vision for Murano that I could get behind. It
would be a tool which allows fully running applications to be
assembled and launched from a catalog of Heat templates (plus some
app lifecycle workflow beyond the scope of this email).<br>
<br>
We could add type interfaces to HOT but I still think duck typing
would be worth considering. To demonstrate, lets assume that when a
template gets cataloged, metadata is also indexed about what
parameters and outputs the template has. So for the case above:<br>
1) User selects an app to launch from the catalog<br>
2) Murano performs a heat resource-type-list and compares that with
the types in the template. The resource-type list is missing
My::App::Database for a resource named my_db<br>
3) Murano analyses the template and finds that My::App::Database is
assigned 2 properties (db_username, db_password) and elsewhere in
the template is a {get_attr: [my_db, db_url]} attribute access.<br>
4) Murano queries glance for templates, filtering by templates which
have parameters [db_username, db_password] and outputs [db_url]
(plus whatever appropriate metadata filters)<br>
5) Glance returns 2 matches. Murano prompts the user for a choice<br>
6) Murano constructs an environment based on the chosen template,
mapping My::App::Database to the chosen template<br>
7) Murano launches the stack<br>
<br>
Sure, there could be a type interface called My::App::Database which
declares db_username, db_password and db_url, but since a heat
template is in a readily parsable declarative format, all required
information is available to analyze, both during glance indexing and
app launching.<br>
<br>
<br>
<blockquote
cite="mid:CAG_6_omGVxuw_nC7nFnpWkZNivnbJ=s-gUd9CcOOr_Q7_pAa8w@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Apr 2, 2014 at 3:30 PM, Steve
Baker <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sbaker@redhat.com" target="_blank">sbaker@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">On 03/04/14 10:39, Ruslan Kamaldinov
wrote:<br>
> This is a continuation of the "MuranoPL questions"
thread.<br>
><br>
> As a result of ongoing discussions, we figured out
that definition of layers<br>
> which each project operates on and has
responsibility for is not yet agreed<br>
> and discussed between projects and teams (Heat,
Murano, Solum (in<br>
> alphabetical order)).<br>
><br>
> Our suggestion and expectation from this working
group is to have such<br>
> a definition of layers, agreement on it and an
approach of reaching it.<br>
><br>
> As a starting point, we suggest the following:<br>
><br>
> There are three layers of responsibility:<br>
> 1. Resources of the cloud<br>
> 2. Applications of the cloud<br>
> 3. Layers specific for Murano and Solum (to be
further discussed and<br>
> clarified, for this discussion it's out of
scope)<br>
><br>
> Layer 1 is obviously covered by Heat.<br>
><br>
> Most of the disagreement is around layer 2. Our
suggestion is to figure out<br>
> the way where we can have common engine, DSL and
approach to apps description.<br>
> For this we'll take HOT and TOSCA as a basis and
will work on addition of<br>
> functionality missing from Murano and Solum point
of view.<br>
><br>
> We'll be happy if existing Heat team continue
working on it, having the full<br>
> control of the project, provided that we agree on
functionality missing there<br>
> from Murano and Solum point of view and addition of
this functionality in a<br>
> systematic way.<br>
><br>
> Let me outline the main concern in regards to HOT
from Murano perspective.<br>
> Others concerns could be figured out later. The
typical use case for Murano is<br>
> the following:<br>
> Application writer sets a requirement for her
application to use RDBMS<br>
> assuming that it can be MySQL, PostgreSQL or MSSQL.
HOT engine should be able<br>
> to understand such requirements and be able to
satisfy them by instantiating<br>
> instances with DB. End user should be able to
control which particular type of<br>
> DB should be used. This is quite similar to
abstract requirements described in<br>
> TOSCA. As Heat wants to cover TOSCA format too this
Murano requirement is<br>
> pretty well aligned with what HOT\TOSCA can
provide.<br>
><br>
><br>
> Hopefully this functionality can be introduced into
HOT. Solum and Murano will<br>
> leverage it by using some common API, and
implementing layer 3 as thin as<br>
> possible.<br>
><br>
> Again, this is only suggested starting point,
something to begin with.<br>
><br>
</div>
</div>
Thanks for bring this discussion back to solving specific
problems. The<br>
above database abstraction can be nicely represented using
HOT<br>
environments and provider resources [1].<br>
<br>
Take the following template snippet:<br>
<br>
resources:<br>
my_db:<br>
type: My::Database<br>
properties:<br>
# ...<br>
<br>
my_server<br>
type: OS::Nova::Server<br>
properties:<br>
# ... including a {get_attr: [my_db, connection_url]}<br>
<br>
My::Database is a type defined in the environment which is
included in<br>
the stack-create call. Different environments can provide
different<br>
database implementations, for example:<br>
<br>
resource_registry:<br>
"My::Database": path/to/trove_wrapper.yaml<br>
<br>
resource_registry:<br>
"My::Database": path/to/nova_galera_ubercluster.yaml<br>
<br>
resource_registry:<br>
"My::Database": path/to/postgresql.yaml<br>
<br>
Each of these templates could be implemented to have the
same parameters<br>
and outputs so the template will work with any of these
resource<br>
provider templates.<br>
<br>
One thing we could consider adding to HOT is allow the
defining of a<br>
type interface, and validating that a given
template/resource implements<br>
its declared interfaces. However the above example works
just fine<br>
without interfaces, and this duck-typing approach may
provide a better<br>
user experience anyway.<br>
<br>
[1] <a moz-do-not-send="true"
href="http://docs.openstack.org/developer/heat/template_guide/environment.html"
target="_blank">http://docs.openstack.org/developer/heat/template_guide/environment.html</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>