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 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.
Proposed new table structure:
|OPNFV project||OPNFV Requirement||Lead Contributor||Blueprint||OPNFV Status||OpenStack Status||openstack project|
|Link to the OPNFV Project|| ||Lead Contributor|| ||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 email@example.com or email firstname.lastname@example.org 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|
Relevant process pages:
A good blueprint has the following characteristics:
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):
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:
Some additional links on successfully shepherding blueprints through review:
Many members of the OPNFV group are active in the Telco working group in OpenStack.
to be completed…