<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 22, 2014 at 4:53 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Angus Salkeld's message of 2014-08-21 20:14:12 -0700:<br>
<div><div class="h5">> On Fri, Aug 22, 2014 at 12:34 PM, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
><br>
> > Excerpts from Georgy Okrokvertskhov's message of 2014-08-20 13:14:28 -0700:<br>
> > > During last Atlanta summit there were couple discussions about<br>
> > 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>
> > > *App Catalog API to Catalog Program*<br>
> > ><br>
> > > Application Catalog part can belong to Catalog program, the package<br>
> > > repository will move to artifacts repository part where Murano team<br>
> > already<br>
> > > participates. API part of App Catalog will add a thin layer of API<br>
> > 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>
> > 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>
> > ><br>
> > > Murano engine orchestrates the Heat template generation. Complementary<br>
> > 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<br>
> > 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>
> > >    - orchestrate multiple Heat stacks - DR deployments, HA setups,<br>
> > 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>
> > >    to handle issues and implement additional logic around error handling<br>
> > and<br>
> > >    self-healing.<br>
> ><br>
> > 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>
> ><br>
><br>
> "get off my lawn";)<br>
><br>
<br>
</div></div>And turn down that music!<br>
<br>
Sorry for the fist shaking, but I wan to highlight that I'm happy to<br>
consider it, just not with programs working the way they do now.<br>
<div class=""><br>
> <a href="http://stackalytics.com/?project_type=all&module=murano-group" target="_blank">http://stackalytics.com/?project_type=all&module=murano-group</a><br>
><br>
> HP seems to be involved, you should check it out.<br>
><br>
<br>
</div>HP is involved in a lot of OpenStack things. It's a bit hard for me to<br>
keep my eyes on everything we do. Good to know that others have been able<br>
to take some time and buy into it a bit. +1 for distributing the load. :)<br>
<div class=""><br>
> > 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>
> ><br>
><br>
> I thought you were saying that opsworks was neat the other day?<br>
> Murano from what I understand was partly inspired from opsworks, yes<br>
> it's a layer up, but still really the same field.<br>
><br>
<br>
</div>I was saying that OpsWorks is reportedly popular, yes. I did not make<br>
the connection at all from OpsWorks to Murano, and nobody had pointed<br>
that out to me until now.<br>
<div class=""><br>
> > 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>
> ><br>
><br>
> This is exactly what I hope will happen.<br>
><br>
<br>
</div>Which sessions from last summit would we want to give up to make room<br>
for the Murano-only focused sessions? How much time in our IRC meeting<br>
should we give to Murano-only concerns? <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Forgive me for being harsh. We have a cloud to deploy using Heat,<br>
and it is taking far too long to get Heat to do that in an acceptable<br>
manner already. Adding load to our PTL and increasing the burden on our<br>
communication channels doesn't really seem like something that will<br>
increase our velocity. I could be dead wrong though, Murano could be<br>
exactly what we need. I just don't see it, and I'm sorry to be so direct<br>
about saying that.<br></blockquote><div><br></div><div>No problem, we need to understand up front how this is all going to work.<br><br></div><div>AFAIK nova has sub-team meetings and they summarize at the main meeting<br>
</div><div>we could have for instance a convergence/scaling and murano sub team that<br>could do similar.<br></div><div> <br></div><div>I also think Thierry's czar concept would help relieve the pressure on PTL's too.<br>
</div><div><br></div><div>-Angus<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><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>