Page tree
Skip to end of metadata
Go to start of metadata

OPNFV related blueprints

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

OpenStack blueprint processes

Relevant process pages:

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 the release Design Summit, and advocated for the design summit working sessions, to ensure they are included in scope for that release. Blueprints proposed after the Design Summit are not eliminated, but will have a hard time being approved for the upcoming release.

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.

Some additional links on successfully shepherding blueprints through review:

OpenStack release management

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.
  • PTG's are events held at the beginning of a development cycle, every 6 months.
  • 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.

You can find more information about the release schedules on the OpenStack Releases web page.

The current release under development is Pike. The planned release week is Aug 28 - Sep 01, 2017.

There is no blueprint submission deadline for Neutron. Please visit for the Neutron blueprint and spec policy

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.

OPNFV and OpenStack requirements and development collaboration

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 <>. From there,

  • 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.
  • No labels