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
