<div dir="ltr">During last Atlanta summit there were couple discussions about Application Catalog and Application space projects in OpenStack. These cross-project discussions occurred as a result of Murano incubation request [1] during Icehouse cycle.  On the TC meeting devoted to Murano incubation there was an idea about splitting the Murano into parts which might belong to different programs[2].<br>
<br><br>Today, I would like to initiate a discussion about potential splitting of Murano between two or three programs.<br><br><br><b>App Catalog API to Catalog Program</b><br><br>Application Catalog part can belong to Catalog program, the package repository will move to artifacts repository part where Murano team already participates. API part of App Catalog will add a thin layer of API methods specific to Murano applications and potentially can be implemented as a plugin to artifacts repository. Also this API layer will expose other 3rd party systems API like CloudFoundry ServiceBroker API which is used by CloudFoundry marketplace feature to provide an integration layer between OpenStack Application packages and 3rd party PaaS tools.<br>
<br><br><br><b>Murano Engine to Orchestration Program</b><br><br>Murano engine orchestrates the Heat template generation. Complementary to a Heat declarative approach, Murano engine uses imperative approach so that it is possible to control the whole flow of the template generation. The engine uses Heat updates to update Heat templates to reflect changes in applications layout. Murano engine has a concept of actions - special flows which can be called at any time after application deployment to change application parameters or update stacks. The engine is actually complementary to Heat engine and adds the following:<br>
<br><ul><li>orchestrate multiple Heat stacks - DR deployments, HA setups, multiple datacenters deployment</li><li>Initiate and controls stack updates on application specific events</li><li>Error handling and self-healing - being imperative Murano allows you to handle issues and implement additional logic around error handling and self-healing.<br>
</li></ul><br><br><b>Murano UI to Dashboard Program</b><br><br>Application Catalog requires  a UI focused on user experience. Currently there is a Horizon plugin for Murano App Catalog which adds Application catalog page to browse, search and filter applications. It also adds a dynamic UI functionality to render a Horizon forms without writing an actual code.<br>
<br><br><br><br>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-February/027736.html" rel="noreferrer">http://lists.openstack.org/pipermail/openstack-dev/2014-February/027736.html</a><br><br>[2] <a href="http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-03-04-20.02.log.txt" rel="noreferrer">http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-03-04-20.02.log.txt</a><br>
<br><br><br>--<br>Georgy Okrokvertskhov<br>Architect,<br>OpenStack Platform Products,<br>Mirantis<br><a href="http://www.mirantis.com">http://www.mirantis.com</a><br>Tel. +1 650 963 9828<br>Mob. +1 650 996 3284
</div>