[openstack-dev] [Glance][Heat] Murano split dsicussion
asalkeld at mirantis.com
Fri Aug 22 03:14:12 UTC 2014
On Fri, Aug 22, 2014 at 12:34 PM, Clint Byrum <clint at 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
> > Catalog and Application space projects in OpenStack. These cross-project
> > discussions occurred as a result of Murano incubation request  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.
> > 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
> > participates. API part of App Catalog will add a thin layer of API
> > 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
> > 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,
> > 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
> > 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";)
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.
> 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 at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev