<div dir="ltr"><div class="im" style="font-family:arial,sans-serif;font-size:12.800000190734863px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><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></div></blockquote><div><br></div></div><div style="font-family:arial,sans-serif;font-size:12.800000190734863px">> Are we going to wait for the generic UI (Merlin) or get murano-dashboard into Horizon then work on Merlin?<span class=""><font color="#888888"><br>
</font></span></div><div style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></div><div style="font-family:arial,sans-serif;font-size:12.800000190734863px">Merlin will be a generic library\framework in Horizon for Application projects (Heat, Murano, Solum). We still need to have specific implementations of UI for each project, but these projects will reuse the common code.</div>
<div style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></div><div style="font-family:arial,sans-serif;font-size:12.800000190734863px">We can put existing Murano UI to Dashboard or inside Catalog program as a separate repo. I think it might make sense to keep UI components closer to project rather then keep UI in a separate program.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 6:35 PM, Angus Salkeld <span dir="ltr"><<a href="mailto:asalkeld@mirantis.com" target="_blank">asalkeld@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"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Thu, Aug 21, 2014 at 6:14 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">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></div></blockquote><div><br></div></div><div>Seems to make sense, tho' I am not a glance-core.<br></div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><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></div></blockquote></div><div><br>+1<br><br></div><div>Are the teams going to work as-is from a core reviewer PoV (I'd assume so, just clarifying). I am just wondering how<br></div><div>we can get the Heat and Murano teams to know what each are doing - basically work at least somewhat together.<br>
</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></div></blockquote><div><br></div></div><div>Are we going to wait for the generic UI (Merlin) or get murano-dashboard into Horizon then work on Merlin?<span class="HOEnZb"><font color="#888888"><br><br></font></span></div>
<span class="HOEnZb"><font color="#888888"><div>-Angus<br></div><div> </div></font></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<div dir="ltr"><br><br>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-February/027736.html" rel="noreferrer" target="_blank">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" target="_blank">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" 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>
</div>
<br></div><div class="">_______________________________________________<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>
<br></div></blockquote></div><br></div></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><br clear="all"><div><br></div>-- <br><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">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. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div>
</div>