On Fri, Aug 22, 2014 at 12:34 PM, Clint Byrum <cl...@fewbar.com> wrote:
> Excerpts from Georgy Okrokvertskhov's message of 2014-08-20 13:14:28 -0700: > > 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]. > > > > > > Today, I would like to initiate a discussion about potential splitting of > > Murano between two or three programs. > > > > > > *App Catalog API to Catalog Program* > > > > 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. > > > > > > I thought this was basically already agreed upon, and that Glance was > just growing the ability to store more than just images. > > > > > *Murano Engine to Orchestration Program* > > > > 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: > > > > > > - orchestrate multiple Heat stacks - DR deployments, HA setups, > multiple > > datacenters deployment > > These sound like features already requested directly in Heat. > > > - Initiate and controls stack updates on application specific events > > Sounds like workflow. :) > > > - Error handling and self-healing - being imperative Murano allows you > > to handle issues and implement additional logic around error handling > and > > self-healing. > > Also sounds like workflow. > > > > > > I think we need to re-think what a program is before we consider this. > > I really don't know much about Murano. I have no interest in it at > "get off my lawn";) http://stackalytics.com/?project_type=all&module=murano-group HP seems to be involved, you should check it out. > all, and nobody has come to me saying "If we only had Murano in our > orchestration toolbox, we'd solve xxx." But making them part of the > I thought you were saying that opsworks was neat the other day? Murano from what I understand was partly inspired from opsworks, yes it's a layer up, but still really the same field. > Orchestration program would imply that we'll do design sessions together, > that we'll share the same mission statement, and that we'll have just > This is exactly what I hope will happen. -A > one PTL. I fail to see why they're not another, higher level program > that builds on top of the other services. > > > > > > > *Murano UI to Dashboard Program* > > > > 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. > > > > > > I feel like putting all the UI plugins in Horizon is the same mistake > as putting all of the functional tests in Tempest. It doesn't have the > affect of breaking the gate but it probably is a lot of burden on a > single team. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev