<div dir="ltr"><div>I'm trying to think how the process is looks like from the application provider point of view. </div><div>As application provider I need to:</div><div>1) Develop a new application, using 3rd party components (DB, Application Container, Cache, Messaging etc).</div>
<div>2) Build and test my application</div><div>2) Upload the deployment artifact to the application catalog</div>3) Immediately or by demand of the dependent application to provision the application to the certain environment<div>
4) Automate application run-time management</div><div>5) Upgrade the application</div><div>6) Terminate the application</div><div><br></div><div><br></div><div>Now, getting to the underline OpenStack services, I would think about the following combination:</div>
<div>1) Develop, Build, Test and create an deployment artifact - Solum</div><div>2) Manage underline resources for deployment - Solum using Heat</div><div>3) Application Catalog Management - Murano</div><div>4) Application Deployment - Solum (for developed application) and Murano (for dependent services: DB, Cache etc). Heroku BuildPack feature is something I would suggest to embrace.</div>
<div>5) Run-time management - scale, repair, replicate, upgrade etc Solum using Murano</div><div>6) Termination - Solum using Murano</div><div><br></div><div>My 2 cents for the issue.</div><div><br></div><div>Dmitry</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 3:04 AM, Georgy Okrokvertskhov <span dir="ltr"><<a href="mailto:gokrokvertskhov@mirantis.com" target="_blank">gokrokvertskhov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>Thanks</div><div>Georgy</div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Wed, Apr 2, 2014 at 3:30 PM, Steve Baker <span dir="ltr"><<a 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><div>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 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>
<div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div dir="ltr"><font color="#999999"><span style>Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. <a href="tel:%2B1%20650%20963%209828" value="+16509639828" target="_blank">+1 650 963 9828</a><br>
Mob. <a href="tel:%2B1%20650%20996%203284" value="+16509963284" target="_blank">+1 650 996 3284</a></font><br></div>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>