On Fri, Aug 22, 2014 at 4:53 PM, Clint Byrum <[email protected]> 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 <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
