User Tools

Site Tools


Process Change Proposal/Discussion page

OPNFV OpenStack community page

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:

OPNFV Requirement Lifecycle proposal

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.

OPNFV Requirement to OpenStack Blueprint process

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:

OPNFV project OPNFV Requirement Lead Contributor Blueprint OPNFV Status OpenStack Status openstack project
Link to the OPNFV Project repository/requirements/reference_document.rst Lead Contributor repository/design_docs/reference_document.rst Status of the draft Submitted/Review/Appr os Target project for the BP
Doctor Unavailability of physical resource Ryota Mibu New nova API call to mark nova-compute down. Under Review Unsubmitted Nova

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 or email to schedule a review on the weekly technical review call. This process is likely to evolve soon.

Current table structure.

OpenStack Project Blueprint name OPNFV project driving Lead contributor Status
Ceilometer Add independent alarm report mechanism HA for OPNFV Zhang Shaoman Drafting
Real-time instance monitoring and notification-based alarm management Doctor Ryota Mibu Superseded
Instance State Notification Doctor Ryota Mibu Under review
Event Publisher for Alarm Doctor Ryota Mibu Under review
Notification-driven Alarm Evaluator Doctor Ryota Mibu Under review
Nova Report host fault to update server state immediately. Doctor Tomi Juvonen Under review
Congress Event-Driven Policy Engine Copper Bryan Sullivan drafting
Congress Data Source Extensions Copper Bryan Sullivan drafting
Keystone Add HA Feature for Keystone Client in Multisite scenario Main: Multisite, Under discussion:HA for OPNFV Zhipeng Huang New and pending
Cinder Add pagination query support for cinder snapshots/backup in a large scale system Multisite Chi Zhang New and pending
Cinder Using Change-Since Filter for Resource Query based on a specified time period for better sync in a large scale system Multisite Zhiyuan Cai New and pending
Heat-Translator Implement new Networking feature in TOSCA Parser Simeon Monov Approved and in working
Neutron OpenStack Service Chaining Framework VNFFG Cathy Zhang Approved and in working

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.

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:

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

Some additional links on successfully shepherding blueprints through review:

OPNFV and OpenStack developer community members

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


to be completed…

community/openstack/process_review.txt · Last modified: 2015/04/21 05:24 by Tomi Juvonen