Open Stack

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
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
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
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.