Open Stack

On Thu, Aug 21, 2014 at 6:14 AM, Georgy Okrokvertskhov <
gokrokvertskhov at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140822/38dd08b6/attachment.html>