User Tools

Site Tools


OPNFV OpenStack community page

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.

OpenStack and OPNFV projects and contacts

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. Regularly 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 to schedule a review on the weekly technical review call.

OpenStack Project Blueprint name Blueprint URL OPNFV project driving Lead contributor Developer Status
Ceilometer Add independent alarm report mechanism HA for OPNFV Zhang Shaoman Abandoned (Liberty) in favour of Monasca approach
Event Alarm Evaluator Doctor Ryota Mibu Ryota Mibu Completed (Liberty)
Nova New nova API call to mark nova-compute down Doctor Tomi Juvonen Roman Dobosz Completed (Liberty)
Support forcing service down Doctor Tomi Juvonen Carlos Goncalves Completed (Liberty)
Get valid server state Doctor Tomi Juvonen Tomi Juvonen Completed (Mitaka)
Get servers filtered by host status Doctor Tomi Juvonen Tomi Juvonen In review (Newton)
Add notification for service status change Doctor Balazs Gibizer Balazs Gibizer Completed (Mitaka)
(VNF_Geo_site_redundancy)Expose quiesce unquiesce api Multisite Chaoyi Huang Zhenyu Zheng In development (Mitaka)
Congress Event-Driven Policy Engine Copper Bryan Sullivan roadmap (post-R1)
Data Source Extensions Copper Bryan Sullivan roadmap (post-R1)
Keystone (multisite identity service management)Can't specify identity endpoint for token validation among several keystone servers in keystonemiddleware Multisite, HA for OPNFV Chaoyi Huang / Hans Feldt Completed (Liberty) (Bug # 1405717)
OpenStack Hierarchical Administrative Framework ONOSFW Prakash Ramchandran Stalled
Cinder Add pagination query support for cinder snapshots/backup in a large scale system Multisite Chi Zhang Completed (Liberty)
Using Change-Since Filter for Resource Query based on a specified time period for better sync in a large scale system Multisite Zhiyuan Cai Stalled
(VNF_Geo_site_redundancy)Get replicated volume ref for DR Multisite Wang Hao Work In Progress
new cinder API call to mark cinder-volume down Doctor Wenjuan Dong Work In Progress
Support forcing service down (CLI) Doctor Wenjuan Dong Work In Progress
Heat-Translator Implement new Networking feature in TOSCA Parser Simeon Monov Completed (Liberty)
Neutron OpenStack Service Chaining Framework VNFFG Cathy Zhang Superseded (networking-sfc and/or Tacker)
Allow admin to mark agents down Doctor Carlos Goncalves Carlos Goncalves Stalled (Incomplete)
(VNF High Availability across VIM)ml2 cross backends extension spec Multisite Shi Hanzhang Shi Hanzhang Work In Progress

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 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:

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.
  • 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; consolidated cross-project schedule. All projects follow the Mitaka release schedule except Nova and Cinder, which are listed under Project-specific events.

  • 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: Newton 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.

OpenStack project reform

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

OpenStack Summits


community/openstack.txt · Last modified: 2016/03/10 08:30 by Ildiko Vancsa