On Thu, Aug 21, 2014 at 6:14 AM, Georgy Okrokvertskhov < gokrokvertsk...@mirantis.com> 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. > > Seems to make sense, tho' I am not a glance-core. > > > *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. > > > +1 Are the teams going to work as-is from a core reviewer PoV (I'd assume so, just clarifying). I am just wondering how we can get the Heat and Murano teams to know what each are doing - basically work at least somewhat together. > > *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. > > > Are we going to wait for the generic UI (Merlin) or get murano-dashboard into Horizon then work on Merlin? -Angus > > > [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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev