Hi,
Let me comment on the reasons why we’ve suggested adding Murano engine to Orchestration program. If we consider the previous Murano incubation discussions, we see that an overlap with the Orchestration program was one of the TC’s concerns. We also find that it was the Heat team that proposed to split Murano into specific parts. As for items a) and b) highlighted by Zane, we definitely shared some of these concerns, but we were guided by TC feedback from the previous Murano incubation review that recommended splitting Murano into separate components. We are fine with having separate program or joining existing programs. In the current situation with Glance mission changed to more generic Catalog mission and Orchestration program mission covering everything it is better to joining existing programs rather than trying to add a new one stepping on everyone’s foot. If the Orchestration program team believes that Murano does not intersect with the mission of the Orchestration program and should start its own program, let’s send this message to the TC and Murano team is ready to go this route. Thanks Georgy On Fri, Aug 22, 2014 at 6:29 AM, Zane Bitter <zbit...@redhat.com> wrote: > > On 21/08/14 04:30, Thierry Carrez wrote: >> >> Georgy Okrokvertskhov wrote: >>> >>> 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. >>> [...] >> >> >> I think the proposed split makes a lot of sense. Let's wait for the >> feedback of the affected programs to see if it's compatible with their >> own plans. > > > I want to start out by saying that I am a big proponent of doing stuff that makes sense, and wearing my PTL hat I will support the consensus of the community on whatever makes the most sense. > > With the PTL hat off again, here is my 2c on what I think makes sense: > > * The Glance thing makes total sense to me. Murano's requirements should be pretty much limited to an artifact catalog with some metadata - that's bread and butter for Glance. Murano folks should join the Glance team and drive their requirements into the artifact catalog. > > * The Horizon thing makes some sense. I think at least part of the UI should be in Horizon, but I suspect there's also some stuff in there that is pretty specific to the domain that Murano is tackling and it might be better for that to live in the same program as the Murano engine. I believe that there's a close analogue here with Tuskar and the TripleO program, so maybe we could ask them about any lessons learned. Georgy suggested elsewhere that the Merlin framework should be in Horizon and the rest in the same program as the engine, and that would make total sense to me. > > * The Heat thing doesn't make a lot of sense IMHO. I now understand that apparently different projects in the same program can have different core teams - which just makes me more confused about what a program is for, since I thought it was a single team. Nevertheless, I don't think that the Murano project would be well-served by being represented by the Heat PTL (which is, I guess, the only meaning still attached to a "program"). I don't think they want the Heat PTL triaging their bugs, and I don't think it's even feasible for one person to do that for both projects (that is to say, I already have a negative amount of extra time available for Launchpad just handling Heat). I don't think they want the Heat PTL to have control over their design summit sessions, and if I were the PTL doing that I would *hate* to be in the position of trying to balance the interests of the two projects - *especially*, given that I am in Clint's camp of not seeing a lot of value in Murano, when one project has not gone through the incubation process and therefore there would be no guidance available from the TC or consensus in the wider community as to whether that project warranted any time at all devoted to it. In fact, I would go so far as to say that it's completely unreasonable to put a single PTL in that position. > > So, I don't think putting the Murano engine into the Orchestration program is being proposed because it makes sense. I think it's being proposed, despite not making sense, because people consider it unlikely that the TC would grant Murano a separate program due to some combination of: > > (a) People won't think Murano is a good (enough) idea - in which case we shouldn't do it (yet); and/or > (b) People have an irrational belief that projects are lightweight but programs are heavyweight, when the reverse is true, and will block any new programs for fear of letting another person call themselves a PTL - in which case the structure of the OpenStack community is broken and we must fix it. > > Y'all know my proposed solution to the latter already - rename programs to projects and get rid of PTLs :) > > cheers, > Zane. > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
