Open Stack

On Fri, Aug 22, 2014 at 4:53 PM, Clint Byrum <clint at fewbar.com> wrote:

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

No problem, we need to understand up front how this is all going to work.

AFAIK nova has sub-team meetings and they summarize at the main meeting
we could have for instance a convergence/scaling and murano sub team that
could do similar.

I also think Thierry's czar concept would help relieve the pressure on
PTL's too.

-Angus


> _______________________________________________
> 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/4319963c/attachment.html>