Open Stack

Excerpts from Angus Salkeld's message of 2014-08-21 20:14:12 -0700:
> 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";)
> 

And turn down that music!

Sorry for the fist shaking, but I wan to highlight that I'm happy to
consider it, just not with programs working the way they do now.

> http://stackalytics.com/?project_type=all&module=murano-group
> 
> HP seems to be involved, you should check it out.
> 

HP is involved in a lot of OpenStack things. It's a bit hard for me to
keep my eyes on everything we do. Good to know that others have been able
to take some time and buy into it a bit. +1 for distributing the load. :)

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

I was saying that OpsWorks is reportedly popular, yes. I did not make
the connection at all from OpsWorks to Murano, and nobody had pointed
that out to me until now.

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

Which sessions from last summit would we want to give up to make room
for the Murano-only focused sessions? How much time in our IRC meeting
should we give to Murano-only concerns?

Forgive me for being harsh. We have a cloud to deploy using Heat,
and it is taking far too long to get Heat to do that in an acceptable
manner already. Adding load to our PTL and increasing the burden on our
communication channels doesn't really seem like something that will
increase our velocity. I could be dead wrong though, Murano could be
exactly what we need. I just don't see it, and I'm sorry to be so direct
about saying that.