Open Stack

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

"get off my lawn";)

http://stackalytics.com/?project_type=all&module=murano-group

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.

-A


> 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
> 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/25e0ad7c/attachment.html>