<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 22, 2014 at 12:34 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from Georgy Okrokvertskhov's message of 2014-08-20 13:14:28 -0700:<br>
<div class="">> During last Atlanta summit there were couple discussions about Application<br>
> Catalog and Application space projects in OpenStack. These cross-project<br>
> discussions occurred as a result of Murano incubation request [1] during<br>
> Icehouse cycle.  On the TC meeting devoted to Murano incubation there was<br>
> an idea about splitting the Murano into parts which might belong to<br>
> different programs[2].<br>
><br>
><br>
> Today, I would like to initiate a discussion about potential splitting of<br>
> Murano between two or three programs.<br>
><br>
><br>
</div>> *App Catalog API to Catalog Program*<br>
<div class="">><br>
> Application Catalog part can belong to Catalog program, the package<br>
> repository will move to artifacts repository part where Murano team already<br>
> participates. API part of App Catalog will add a thin layer of API methods<br>
> specific to Murano applications and potentially can be implemented as a<br>
> plugin to artifacts repository. Also this API layer will expose other 3rd<br>
> party systems API like CloudFoundry ServiceBroker API which is used by<br>
> CloudFoundry marketplace feature to provide an integration layer between<br>
> OpenStack Application packages and 3rd party PaaS tools.<br>
><br>
><br>
<br>
</div>I thought this was basically already agreed upon, and that Glance was<br>
just growing the ability to store more than just images.<br>
<br>
><br>
> *Murano Engine to Orchestration Program*<br>
<div class="">><br>
> Murano engine orchestrates the Heat template generation. Complementary to a<br>
> Heat declarative approach, Murano engine uses imperative approach so that<br>
> it is possible to control the whole flow of the template generation. The<br>
> engine uses Heat updates to update Heat templates to reflect changes in<br>
> applications layout. Murano engine has a concept of actions - special flows<br>
> which can be called at any time after application deployment to change<br>
> application parameters or update stacks. The engine is actually<br>
> complementary to Heat engine and adds the following:<br>
><br>
><br>
</div>>    - orchestrate multiple Heat stacks - DR deployments, HA setups, multiple<br>
>    datacenters deployment<br>
<br>
These sound like features already requested directly in Heat.<br>
<br>
>    - Initiate and controls stack updates on application specific events<br>
<br>
Sounds like workflow. :)<br>
<br>
>    - Error handling and self-healing - being imperative Murano allows you<br>
<div class="">>    to handle issues and implement additional logic around error handling and<br>
>    self-healing.<br>
<br>
</div>Also sounds like workflow.<br>
<br>
><br>
<br>
<br>
I think we need to re-think what a program is before we consider this.<br>
<br>
I really don't know much about Murano. I have no interest in it at<br></blockquote><div><br></div><div>"get off my lawn";)<br><br><a href="http://stackalytics.com/?project_type=all&module=murano-group">http://stackalytics.com/?project_type=all&module=murano-group</a><br>
<br></div><div>HP seems to be involved, you should check it out.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
all, and nobody has come to me saying "If we only had Murano in our<br>
orchestration toolbox, we'd solve xxx." But making them part of the<br></blockquote><div><br></div><div>I thought you were saying that opsworks was neat the other day?<br></div><div>Murano from what I understand was partly inspired from opsworks, yes<br>
</div><div>it's a layer up, but still really the same field.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Orchestration program would imply that we'll do design sessions together,<br>
that we'll share the same mission statement, and that we'll have just<br></blockquote><div><br></div><div>This is exactly what I hope will happen.<br><br></div><div>-A<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

one PTL. I fail to see why they're not another, higher level program<br>
that builds on top of the other services.<br>
<br>
><br>
><br>
> *Murano UI to Dashboard Program*<br>
<div class="">><br>
> Application Catalog requires  a UI focused on user experience. Currently<br>
> there is a Horizon plugin for Murano App Catalog which adds Application<br>
> catalog page to browse, search and filter applications. It also adds a<br>
> dynamic UI functionality to render a Horizon forms without writing an<br>
> actual code.<br>
><br>
><br>
<br>
</div>I feel like putting all the UI plugins in Horizon is the same mistake<br>
as putting all of the functional tests in Tempest. It doesn't have the<br>
affect of breaking the gate but it probably is a lot of burden on a<br>
single team.<br>
<div class=""><div class="h5"><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>
</div></div></blockquote></div><br></div></div>