On 08/20/2014 10:14 PM, Georgy Okrokvertskhov wrote: > 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. > >
Makes sense to me! Is this just going to consume the artifacts API? or will it require some changes to it? Flavio > > *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 > * Initiate and controls stack updates on application specific events > * Error handling and self-healing - being imperative Murano allows you > to handle issues and implement additional logic around error > handling and self-healing. > > > > *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. > > > > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2014-February/027736.html > > [2] > http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-03-04-20.02.log.txt > > > > -- > Georgy Okrokvertskhov > Architect, > OpenStack Platform Products, > Mirantis > http://www.mirantis.com > Tel. +1 650 963 9828 > Mob. +1 650 996 3284 > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- @flaper87 Flavio Percoco _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev