This page to be developed. Rather than establish a project for OpenStack the OPNFV community has agreed to work on establishing focus community groups where we will describe community engagement practices, identify community leaders, manage our contributions toward those communities and generally get ourselves organised well enough to be a benefit, rather than a burden, to our source communities.

Information we should get up here asap:

The requirement handling process in OPNFV provides two documents under revision control in OPNFV that are of interest to OpenStack community blueprint handling.

• The OPNFV Requirement description document repository/requirements/reference_document.rst
• The OPNFV blueprint proposal document repository/design_docs/reference_document.rst

The Requirement document should describe the motivation for the features needed in OPNFV including references to the documented use cases captured by the requirements project and all requirements listed with reference to associated blueprints or upstream development proposals needed.

The blueprint proposal document should start as a proposal from the requirement projects and describe the exact requirement on a particular upstream component in such a way as to describe the implementation of that requirement for that project. This should be an atomic description of the specific requirement and provide needed links to associated requirements and design documents.
Once the blueprint has been reviewed and achieves maturity and clarity on what it intends to implement, lists requirements, use cases and intention sufficiently well it should be migrated to the OpenStack specs repository for review, design and development.
The intention is not to perform development analysis in OPNFV, but to ensure when we engage the OpenStack community we have sufficient clarity in the proposal that a design discussion can occur.

OpenStack blueprint templates: Nova Template Celiometer Template Neutron Template Sahara Template

Proposed new table structure:

Blueprint status can be "Work in progress" (blueprint being actively edited), "Under review" (blueprint is final and submitted for review), "Approved" (approved for inclusion, development work not yet started), "In development", "Completed" (work accepted upstream), "Rejected" (not approved for inclusion), "Deferred" (to be submitted for next release).

If you have a blueprint which you would like reviewed, contact Dave Neary dneary@redhat.com or email opnfv-tech-discuss@lists.opnfv.org to schedule a review on the weekly technical review call. This process is likely to evolve soon.

Current table structure.

Relevant process pages:

• Release cycle
• Blueprint documentation
• Kilo release cycle
• Nova Liberty blueprint template

A good blueprint has the following characteristics:

• Explains the context of the blueprint - the high level use-case which requires the feature
• Explains the feature request in a generic, non-NFV-specific manner
• Provides some specification details on how the feature will be implemented
• Uses the project's spec template (located in specs/template.rst of the project "specs" repo, typically)

This provides the material for an informed, useful discussion upstream of the feature and whether the proposed approach is the best way to accomplish the high level goal.

It is possible to get code into OpenStack without going through the Blueprint process by submitting a patch for review directly, but it does not make it easier to get the code accepted.

From Release Cycle document upstream:

The Planning stage is at the start of a cycle, just after the
previous release, when we take a step back and focus on what we want
to do for the next one. We discuss it with our peers to get their
feedback and comments, in most cases proposing a spec document that
precisely describes how we want to do it. It usually lasts 4 weeks,
with the Design Summit on the third week.

In general, the review period has lasted until the first milestone release, between 6 and 8 weeks after the previous release.

Key dates for Kilo (with special attention on Nova):

• Sept 30: Juno release date
• Sept 30 - Dec 18: Kilo planning
• Oct 7: Nova Kilo specs open for review
• Week of Nov 6: Paris summit
• Dec 18: kilo-1 milestone, Nova spec approval soft deadline
• Jan 22: Nova non-priority feature code proposal, Nova spec hard deadline
• Feb 5: kilo-2 milestone, Nova & Cinder non-priority feature freeze
• Mar 5: Feature proposal freeze
• Mar 19: kilo-3 milestone, feature, string and dependency freeze
• April 30: Kilo release

The Nova team is being even more proactive in Liberty than they were in Kilo. The March 1st date you have been hearing is because Nova Liberty specs are now open for review.

In practice: specs for the Liberty release should be proposed and pre-discussed in advance of the Vancouver summit (May 18-22). There may be some benefit in uploading specs for Liberty now to gain alignment inside OPNFV and refine them, but in the email above, Michael Still (Nova PTL) was clear that he does not expect serious spec review to start until Kilo is out the door on April 30th.

Other projects operate on their own schedule, and have different criteria for when they expect specs to be proposed and approved. For most of them, Liberty blueprint review will not start until after the Kilo release.

Blueprints should be discussed and reviewed online in advance of Vancouver, and advocated for the design summit working sessions, to ensure they are included in scope for Liberty. Blueprints proposed after the Vancouver Summit are not eliminated, but will have a hard time being approved for Liberty.

As a general rule of thumb, the earlier in the cycle you engage with the project teams, the more time you have for features and fixes to land in the release. Make sure that code starts coming in as soon as the spec is approved, as there are cases where time is spent on specs and then code shows up too late to be reviewed in time anyway.

Much of this is in flux, or under discussion - while things should be stable for the Liberty release cycle, changes should be expected in coming releases:

• Dan Berrange's proposal to shorten release cycle:

http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html

• Thierry Carrez's report on the state of project reform:

https://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/

Some additional links on successfully shepherding blueprints through review:

• Rob Hirschfeld's description of the release cycle
• A presentation from Hong Kong on navigating the blueprint process

Many members of the OPNFV group are active in the Telco working group in OpenStack.

• joe.stacker@opngv.org

to be completed…