This page is maintained by OPNFV and OpenStack community members. 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.

See the etherpad page for the OPNFV BoF at the OpenStack Summit Tokyo 2015.

Tokyo 2015 OpenStack Summit

This list of the primary OpenStack and OPNFV projects, with links to the wikis and Project Technical Leaders, is designed to facilitate collaboration. Please follow the blueprint process below to request features in OpenStack.

To facilitate the work of developers submitting blueprints to OpenStack, we have instituted a process for requirements projects which consists of the following:

1. Projects first create an OPNFV requirement document in Markdown in the project repository: repository/requirements/reference_document.rst - this document should describe the goal at a high level for OPNFV consumers
2. A requirement will result in one or more blueprints for a project which should be drafted (one blueprint per file) in repository/design_docs/reference_document.rst
3. These files should be proposed for review in OPNFV's Gerrit, and should follow the OpenStack project's template file (example for Ceilometer)
4. After a successful community sanity check, verifying that the spec has sufficient implementation details and conforms with the minimum expectations of an OpenStack blueprint, the blueprint should be proposed to the upstream project. Proposal is by creation of a Gerrit patch against the "specs" repository of the OpenStack project (Ceilometer specs and sample Ceilometer blueprint review)
5. Community comments are to be expected on a blueprint, and multiple revisions may be required upstream before the spec proposal will be merged

The table below is a summary of the currently in-flight blueprints for OpenStack Mitaka. BEING UPDATED

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, email opnfv-tech-discuss@lists.opnfv.org to schedule a review on the weekly technical review call.

Relevant process pages:

• Project Team Guide including Release Management
• Blueprint documentation
• Mitaka release cycle
• Nova Mitaka 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.

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

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.

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

From the Project Team Guide:

• OpenStack deliverables are released in various ways and on different time-based or feature-based schedules
• What binds them all is a common 6-month development cycle.
• Design Summits are events held at the beginning of a development cycle, every 6 months.
• Midcycle sprints (also named midcycle meetups) are optional project team gatherings that happen between Design Summits.
• The development cycles follow a repeating pattern, which is described in general terms in the Typical Development Cycle Schedule of the Project Team Guide, Release Management section.

Key dates for Mitaka, with emphasis on Nova; detailed schedule:

• Oct 15: Liberty release
• Week of Oct 26: Mitaka Design Summit (Tokyo)
• Dec 1-3: mitaka-1 milestone
• Dec 3: Nova spec freeze
• Jan 19-21: mitaka-2 milestone
• Jan 21: Nova non-priority feature freeze
• Jan 26-28: Nova mid-cycle (TBC)
• Feb 25: FinalLibraryRelease and feature proposal freeze
• Mar 1-3: mitaka-3 milestone, soft feature, string and dependency freeze
• Mar 14-18: Mitaka Release Candidate 1 target, hard freeze
• Mar 28-Apr 1: Final Release Candidates & Intermediary releases
• April 7: Mitaka release
• Week of April 25: N Release Design Summit (Austin)

There is no blueprint submission deadline for Neutron. Please visit for the Neutron blueprint and spec policy. The latest update from the Neutron PTL is found here.

BEING UPDATED: 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.

With Liberty, OpenStack has implemented a Core and "Big Tent" project architecture. This enables a common definition of what constiutes "OpenStack" for interoperability, as well as opens the door to more projects.

• Thierry Carrez's pre-reform report outlines the objectives.
• The revised project governance is documented here.

After the first OPNFV Summit in November 2015, it became clear there would be tremendous value in a consistent means to present OPNFV blueprints and patches to the OpenStack projects. It's important to send your blueprints to opnfv-tech-discuss@lists.opnfv.org, for adding to the table above. From there,

• On a daily or weekly basis, a tool will scan the blueprints from this page
• The tool will create a single Gerrit dashboard of all the patches associated with the open blueprints.
• OpenStack Telco-focused community members will advocate the dashboard with the OpenStack project teams.
• OPNFV blueprint submitters are expected to contribute code to complete the features according to the OpenStack schedule. Visit this page for more information on How to Contribute.
• OPNFV project Pharos provides community testing labs around the world. See locations, status and project assignments here.