Open Stack

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 <zbitter at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140822/5b48fae2/attachment.html>