Open Stack

>From John Garbutt (on a thread that doesn't need to be extended).  Some great philosophy insight on the Nova PTL.





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.



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.



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.



__________________________________________________________________________