This is an old revision of the document!
OPNFV will adopt a bi-annual (twice yearly) cadence derived primarily from the cadence of its major upstream constituents.
The SR plan recognizes the inherent layering in a set of deliverables, which requires that layer N be stable in order for layer N + 1 to begin to stabilize. The schedule accounts for such dependencies through the use of “offsets” between layers. For example, the first SR will have (at least) two layers:
Unless and until the upstream projects are proven to have been successfully pulled into the OPNFV repo and correctly built with the OPNFV tooling, there is little point in running the OPNFV local testing that is designed to go beyond the basic CI and release testing from upstream. For this reason, the date when we can expect to code freeze the basic platform tooling and code needs to occur prior to the code freeze for the layered system tests. To support this the SR has an Offset 0 milestone to freeze the platform bits, which is distinct and separate in time from the Offset 1 for that same milestone (code freeze). If we estimate that it will take two weeks to iterate and converge bug find/fix ratios in the code that constitutes the offset 1 deliverables, the schedule would reflect that by documenting the date for the offset 1 code freeze occurring two weeks later. Additional SR offsets can be proposed and incorporated on-demand, as OPNFV evolution dictates. If (hypothetical, currently out of scope) OPNFV were to begin releasing virtual network functions, it would make sense to create an offset between the system test completion and the completion of test/fix for the VNF “layer”.
Deadlines for Release Candidates (RC0, RC1 and RC1) and the release are the same regardless of offset. Deadlines for M1 and M2 are offset by +1 week and +2 weeks. Full details can be found in the dates in the specific SR schedule.
All of the commitments required of SR member projects shall be made known in writing in the simultaneous release plan on the OPNFV wiki before projects can apply to join. It is not fair to projects to change (and particularly to add) commitments after projects have agreed to participate. If we learn that additional SR requirements make sense, every effort should be made to treat them as suggestions in any ongoing SR, and to wait to make them requirements until the next SR planning stage.
The OPNFV SR plan must be approved by the OPNFV Technical Steering Committee before its terms become binding. Milestone 0, SR open for participation, must be scheduled at a date after the TSC has approved the SR plan. The TSC shall post one or more draft SR plans to inform community planning, but only the approved plan, dates and commitments are binding.
The first Release of OPNFV platform will be aimed at March 15, 2015. The basic approach for this release is to build all of the upstream stable projects and run some additional NFV-centric testing on the resulting artifacts. In support of this, the (draft) OPNFV SR 1.0 release plan is designed with Offset 0 and Offset 1 milestones.
These dates are included only to enable a community discussion about what the correct dates should be. In particular, we need to define M0 and M1 and agree to them in order to start the process and enable maximum time for the rest of the SR steps to occur.
Assumption below is that because this is the first release defined during the initial creation of the OPNFV processes and community, there are unique requirements that we will recognize including: • TSC has agreed our goal is keep it simple and do little more than pull together our upstream dependencies in a single “distribution” and demonstrate that the resulting system can be used to support “NFV” by some definition • TSC has sponsored creation of an initial set of projects related to systems and infrastructure that will be relied upon to turn the various source code and binary artifacts into the platform that is the output of OPNFV project. • The bootstrap capabilities provided by these initial projects means they, of course, need to be part of the first SR.
Milestone Offset 0 Offset 1 Event PP0 11/11/14 11/11/14 TSC Begins approving project proposals. M0 11/18/14 11/18/14 Simultaneous Release Open M1 12/2/14 12/09/14 1. Projects Must Have Declared their intent to participate in the simultaneous release
2. Participating projects must have published a candidate Release Plan for public comment ( Release Plan Template )
M2 12/16/14 12/23/14 Participating Projects must have declared their final Release Plan M3 12/23/14 12/30/14 Latest possible Continuous Integration Test Start M4 2/1/15 02/08/15 1. API Freeze
2/15/15 02/22/15 2. Latest possible Continuous System Test Start
M 5 2/1/15 1. Code Freeze (bug fixes only from here)
2. String Freeze (all internationalizable strings frozen to allow translation time) 3. Latest possible date for commencing User facing Documentations
RC0 2/22/15 03/01/15 First Release Candidate RC1 3/1/15 03/04/15 Second Release Candidate RC2 3/8/15 03/08/15 1. Final Release Candidate
2. Participating Projects must hold their Release Reviews, including User Facing Documentation.
FR 3/15/15 03/15/15 Formal Release MR0 4/15/15 04/15/15 First Maintenance Release MR1 6/14/15 06/14/15 Second Maintenance Release MR- N How Many MR do we want to show?
Sept 2015 6 Months after our first and 3 months after Kilo we bring second OPNFV SR.
Spring 2016 TBD Fall 2016 TBD Schedule Milestones To avoid major surgery during the time when test/fix cycle is trying to converge we will define “quiet” times imposing constraints like API Freeze, Feature Freeze, and a series of release candidates. Dates for these milestones will be backed out of the release target dates and based on estimates of the work required. In a true “continuous delivery” environment it may turn out that the delta between grabbing the head of dev tree and shipping an SR may approach zero. The initial release will probably need to support some element of non-automated testing and will need an appropriate cycle time and number of cycles to get to release quality.
Basic Layers in OPNFV CI Build At any given point in OPNFV release cycle we can expect to combine a number of different layers source module and resulting artifacts to provide the OPNFV value add. 1. Stable branches and artifacts from upstream projects 2. Transient patches, which will move to the upstream project at a convenient time 3. OPNFV native projects which will continue to live in the OPNFV repo and be built as value add on top of upstream projects. Functionality and logic will move between 1 and 2 but should be transparent to the function of the resulting artifacts. Requirements for Participation In order to participate in the simultaneous release, a project must do the following things. 1. Planning • Projects must declare their intent to participate in the Simultaneous Release by M1. This is accomplished by adding the project to the table in participating projects and sending the first milestone readout mail. • Participating projects must publish a candidate Release Plan by M1 and declare their final Release Plan by M2 • Participating project Release Plans must contain Milestones that minimally line up with the Simultaneous Release Plan Milestones 2. Leadership & Communication • Each project must elect a Project Lead as described in the TSC charter, section 7. • Phil Robb will help projects with this process and it must be completed by M1. • The results of the election, and other changes to the project lead during this release, should be reported by 1. Updating the project facts template for the project on its main wiki page 2. Updating the participating projects table of this release 3. Sending an e-mail the <project>-dev, release, and tsc lists • The Project Lead is expected to be responsible for the the project meeting deadlines, interacting with other projects, and interacting with the TSC • The Project Lead will be subscribed to the release mailing list and must respond to requests send to the a timely fashion, i.e., 48 hours excluding weekends • If a Project Lead is not be able to do so, they should (i) have somebody else stand in and do this on their behalf, (ii) send a mail to the release mailing list indicating this and the time period, and (iii) note the same information in the participating projects section of the release plan. • All release-critical correspondence will have a subject line containing "PLEASE RESPOND BY <DATE> <UTC-TIME>" • Please limit traffic to correspondence directly relating to the release • The TSC should collect response time metrics for projects both to inform our planning and for project maturity going forward. 3. Service Release Participation • All projects participating in the release are also required to participate in the stability releases after the formal release 4. Modularity • Modules that are not intended to interface with the controller via REST/other RPC mechanism must be OSGI bundles • OSGI bundles should be reasonably granular 5. Quality • No later than M2 as part of the Gerrit/Jenkins merge process participating projects must push their binary artifacts to the Nexus repository • No later than M2, each project must have a Jenkins Job which rebuilds and retests to an appropriate level when a project it depends on publishes new artifacts • No later that M2, each project primarily written in Java must be reporting unit test coverage via sonar 6. Documentation • Each participating project is expected to identify the kinds of documentation that would be useful (e.g., installation guide, user guide, developer guide) and provide them as part of the release. 7. Code Hygiene • No uses of System.out.println in non-test code. • No dependencies on 3rd party snapshot versions • Willing to use agreed-upon versions for dependencies (both 3rd party and ODL), i.e., to eliminate version skew 8. Distribution • All projects must support an X86? PC Bios? What can we assume about exec environment? 9. Meeting Deadlines • All projects are expected to meet the deadlines laid out in the schedule below. • If a project cannot make a deadline, the project lead must write a summary of what was missed, why, the course correction that will be taken, and it's impact on other projects. • For offset two project this is mainly intended to be reflective and to help inform the release process • For offset zero and offset two projects, this should be completed with 24 hours of missing the deadline and must be presented to the TSC at the first TSC meeting after the deadline • All Milestone deliverables will be verified by the OPNFV release management staff and/or the TSC. • NOTE: For deliverables defined only in the project's release plan—and not as a requirement in this document—the release management staff and/or TSC will verify that the status of the deliverables has been reported. OPNFV release management staff and/or the TSC may also, but are not required to, verify the delivered functionality. Milestones, Release Candidates, and Service Releases • Milestones are spaced roughly 4 weeks apart taking into account significant holidays. • Release Candidates (RC) are spaced 2 weeks apart • Service Releases are roughly 6 weeks and 12 weeks after the Formal OPNFV Release.