This section covers the new structure of the Neutron team, which will closely match the Nova team by having a separate neutron-drivers team which will be tasked with approving specs. This team is being instituted to ensure a consistent architectural vision for the Neutron project, and to continue to disaggregate and share the responsibilities of the Neutron PTL.
Given the amount of specifications proposed in neutron-specs, a fast turnaround is needed for both submitters as well as reviewers. In the Juno cycle, we didn't have this, and we ended up with a backlog of some 120+ specifications in neutron-specs when we hit Spec Proposal Deadline (SPD) and Spec Approval Deadline (SAD). To ensure we lower the number of specs arounding during SPD/SAD in Kilo, we need to have a highly focused specification review team.
I'm proposing we adopt a "neutron-drivers" team, similar to "nova-drivers." This team will be composed of core team members who have shown a propensity to review specifications in a timely manner, and an interest in the architectural side of Neutron. The idea is that specification reviewers will be spending 5-10 hours a week reviewing and commenting on specifications, and working with specification contributors to ensure high quality, mergeable specifications which move Neutron forward in a positive direction.
Some specifics of this proposal include:
- A weekly meeting to go over specs with the neutron-drivers team.
- Closely tracked metrics on specs reviews for neutron-drivers members.
- Collaboration in driving community features of Neutron forward in a coherent manner.
- Ability to +A specs in neutron-specs (cores retain +2/-2).
The initial neutron-drivers team will consist of the following people:
- Kyle Mestery
- Maru Newby
- Doug Wiegley
- Akihiro Motoki
- Armando Migliaccio
In addition to driving spec reviews and ensuring consistency of architectural vision for the project, the neutron-drivers team will be responsible for providing focus for the entire project. Ensuring there is focus which spans multiple releases is an important part of ensuring the long-term health of Neutron. Ensuring there is focus during milestone releases is also very important. The neutron-drivers team will be responsible for assisting the PTL at various stages of the release as well.
Guidelines and strategies for rejecting Blueprints
One of the aspects that the Neutron Drivers team needs to take care of is to determine the fate of specs that are targeted against Neutron, which are deemed to be out of scope. Core reviewers and members of the drivers team should strive to ensure that a -2 on a spec is well communicated and understood by the parties affected, in order to avoid unnecessary grief down the release cycle, current and future ones.
The team should also make the effort to motivate the various contributors to stay engaged and active within the larger OpenStack networking ecosystem that we built so tirelessly over the years. For these reasons, the following guidelines are documented below to make sure we attain the aforementioned objectives:
A blueprint targeting Neutron can be 'out of scope' for the following reasons:
- The proposal is sound and fit with the Neutron project, however due to the current cycle's priorities, a -2 means that the work must be 'Deferred' to future cycles to avoid instability to the codebase or prevent a negative impact on the productivity of other efforts; at this point the core reviewer has the option of abandoning the spec on the assumption that the contributor will be resubmitting the spec when the next cycle opens up; exceptions can be assessed on a case by case basis, but generally a -2 for the current cycle is pretty final;
- The proposal is Neutron-related, but it does not fit with the Neutron project's current roadmap; there may be overlap with other proposals, or it needs considerable effort to get it off the ground; a -2 here is a solicitation to the contributor(s) to experiment 'Out-Of-Tree', self-govern, and seek a loosely coupled integration with Neutron; at this point, the interested contributors can still use the spec tool (submit/review patchsets for the spec) and/or the mailing list to collaborate and determine the best way forward. However, at one point the blueprint specification will be abandoned by a member of the drivers team to signal that the specification will not make to Neutron core; contributors are welcomed to submit work against Neutron that enables them to progress, on the assumption they need integration points, and nothing else; these can be submitted via bug fixes or small-scope blueprints. These initiatives should develop in the open, for discoverability and accessibility reasons; in fact an interested Neutron core needs to put in the best position to judge or help the initiative by having full access to what's being produced in the context of the initiative. To this aim, we propose that we keep a catalog in the Neutron repository (a RST file), that enumerates the efforts that may be associated to Neutron. A simple list of (Name, link to publicly hosted repo) should suffice. The parties interested in the initiative have complete self-determination, meaning they can choose how to collaborate, submit blueprints and code, as well as how to test. However, the integration points with the core of Neutron should at least be validated on a regular basis via Continuous Integration, to ensure that the combined system stay sane over time;
- The proposal is wrong from a number of standpoints, design decisions are questionable, and/or the bp may have serious implications regarding security, performance, usability and the other good -ilities of the Neutron system. A -2 here means that the blueprint cannot be resubmitted without a fundamental overhaul; This should be the last resort, especially if the contributor is not willing to accommodate the reviewer's input, after many -1 attempts. The -2 effectively becomes a 'Cease-and-Desist' type of notice. At this point the contributor should give up. This rarely happens, and this case is mentioned for completeness;
To summarize, when a blueprint is marked for abandonment and/or is -2, the following reasons can apply:
- -2 (Deferred): work cannot fit in this cycle, please abandon the current spec, and retarget for next release;
- -2 (Out-Of-Tree): work cannot fit in the project at this time, please develop the work elsewhere and seek guidance on integration points, if required;
- -2 (Out-Of-Scope): work cannot fit in the project as currently being proposed; please revise the approach and resubmit once feedback has been addressed;