Open Stack

This was sent in another thread, but its a quick read out form one the
Nova sessions at the summit that we might want a Nova specific
discussion on...

---------- Forwarded message ----------
From: John Garbutt <john at johngarbutt.com>
Date: 3 June 2015 at 17:57
Subject: Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code
review process (subdir cores)

+1 to ttx and Jame's points on trust and relationships, indeed
referencing the summit session that ttx mentioned:
https://etherpad.openstack.org/p/liberty-cross-project-in-team-scaling

On 3 June 2015 at 16:01, Nikola Đipanov <ndipanov at redhat.com> wrote:
<massive snip>
> This was one of the arguments against doing exactly what you propose in
> Nova - we want the same (high?) level of reviews in all parts of the
> code, and strong familiarity with the whole.
>
> But I think it's failing - Nova is just too big - and there is not
> enough skilled people to do the work without a massive scope reduction.
>
> I am not sure how to fix it TBH (tho my gut feeling says we should
> loosen not tighten the constraints).

So we did have a session on this a the summit:
https://etherpad.openstack.org/p/YVR-nova-liberty-process

I am yet to properly write that up. We don't have a solution, but we
do now have a plan to try and improve things, and it looks something
like this, in no particular order...

Step A is having better developer documentation around the reasons
behind the big strokes of our architecture. This tribal knowledge is
hard to get, and frankly I don't think a single person currently has
the full context here. I am looking for a better something, rather
than an out of date nothing. Perfection here is costly and largely
pointless.
https://blueprints.launchpad.net/nova/+spec/devref-refresh-liberty

Step B is having better / more explicit mentoring for new
contributors, and helping them get started. This includes both
reviewers and those submitting code / features. This effort will help
us improve the artefacts generated by Step 1, so its more useful for
folks gaining context. This used to happen all the time, I feel we got
out of the habit.
https://wiki.openstack.org/wiki/Nova/Mentoring

Step C do a better job of describing WHY we do what we are doing.
Firstly so people know why we do what appear to be crazy things. For
example, Nova might be there first experience of OpenStack, or any
sort of open source development. Secondly, so we can have better
informed conversations about how to improve how we work.

Step D allow self organising sub-teams are now free to decide on top
few patches that are considered "ready to merge" by that subteam and
thus overdue in terms of "ready for nova-core review". Thats happening
in this etherpad:
https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
Increased nova-core focus (as seen during feature freeze) tends to
help things get through the system quickly. Over time, its possible a
subteam might gain enough trust, that we treat their recommendation as
a +2. But we did agree to leave that on the back burner for liberty-1
and see how things progress throughout the liberty release. Its hopped
the addition of tagging in Gerrit might eventually remove the need for
the etherpad.

Step E continue to halt Nova scope creep, and ideally reduce the
scope. The first part is by starting to record what the "tribal
knowledge" says the scope is:
http://docs.openstack.org/developer/nova/devref/project_scope.html
The second part is better seams and contracts between the different
components in Nova. One of the aims of that being that it will be
easier for different groups to work more independently. Much of the
scheduler work is looking to create a more stable interface so its
possible the scheduler (and maybe resource tracker) can gain more
autonomy. The cells v2 work is helping evolve the API <-> compute
interface. The tasks work is likely to help a major evolution of the
virt driver interface. The virt driver interface is also being
improved by the objects work, including formalising image properties
and flavor extra specs. While it may never be practical for any or all
of these things to move out of Nova git tree, looser coupling through
some stricter contracts will help.

Step F review the impact the above ideas are having, and decide where
we go next.

Thanks,
John