User Tools

Site Tools


fuel_opnfv_b-wp

This is an old revision of the document!


Fuel@OPNFV Brahmaputra work-package planning

We plan for three work packages until the Brahmaputra official code-freeze (Milestone E) Jan 5 - 2016. Fuel will apply a soft code freeze policy for the Brahmaputra E-milestone, and will deploy yet another work package (WP4) before the hard code freeze policy is applied, as well as a consolidation phase before Brahmaputra is released.

Work-package 1

Goal:

  • Rebasement of Fuel@OPNFV core to Kilo and Fuel 7.0 (Experimental branch), including build, deploy, test, OPNFV CI-pipeline, Fuel@OPNFV Developers' CI-pipeline…
  • First integration of Brahmaputra integration/collaboration projects (Fuel plug-ins). Goal is to get 4 projects onboard for WP1. Target system state for the integration is Juno and Fuel 6.1 (master branch)
  • Auto deploy of integrated projects.
  • Func-test/Yardstick real or noop verification of integrated projects.

Content:

Work-package 1

Definition of done:

Passing build-, automated deploy- and manual smoke-test.

Due dates:

  • Latest date for integrated projects to sign-up for WP1: Thu November 2 -2015
  • Latest date for a partially functional plugin commit: Tue Nov 10 -2015
  • Latest date for a partially functional plugin demo (Yoytube clip or otherwise): Fri Nov 13 -2015

Work-package 2

Goal:

  • Collaboration/integration project freeze - no more OPNFV integration projects than those integrated at this time will be integrated with Fuel@OPNFV Brahmaputra release - unless they come with upstream project integration in WP3.
  • Plugins/integration projects are required to be (re)based on Kilo/Fuel 7.0.
  • Fuel 7.0/Kilo is merged to master and the experimental branch will be used for Fuel 8.0/Liberty rebasing.

Content:

  • Full Kilo/Fuel 7 integration
  • Fully functional plugins based on Fuel 7
  • Kilo/Fuel 7 merged to master branch, experimental branchto be used for Fuel 8 rebasing

Definition of done:

  • Passing build-, automated deploy- and smoke-test.
  • Definition of supported system state permutations and working automated deploy of those system states

Due dates:

  • Latest date for integrated projects to sign-up for Fuel@OPNFV WP2/Brahmaputra: Fri November 13 -2015
  • Latest date for a functional plugin commit based on Fuel 7/Kilo: Thu Dec 10 -2015
  • Latest date for a functional plugin demo (Yoytube clip or otherwise): Fri Dec 17 -2015

Work-package 3

Goal:

  • Stable Fuel@OPNFV core rebase to Fuel 8.0/Liberty in experimental branch
  • Fully functional end-system-state plugins integrated with master/Fuel 7.0/Kilo
  • Soft code-freeze (no further feature code is allowed)
  • Fuel 8 merged with master branch

Content:

  • Core Fuel@OPNFV rebased to Liberty/Fuel 8 including build, deploy, ci-pipeline, development ci-pipeline, rtc

Definition of done:

Passing build-, install- and part of the full func-test pipe-line.

Due date: Jan 5 -2016

Work-package 4

Goal:

  • Hard code freeze
  • Fuel 8.0/Liberty rebase stable builds based on good/bad commit indications from Fuel upstream CI
  • Fully functional end-system-state plugins integrated with master/Fuel 8.0/Liberty
  • stable/brahmaputra branch created
  • master branch is opened up for C-release development

Definition of done:

  • Passing build-, install- and most of the func-test for each of the system state permutations.
  • Stability review 1

Due date: Jan 15 -2016

Consolidation

Content:

  • (1)Stability review 1: Jan 15 -2015
  • (1)Stability review 2: Jan 22 -2015
  • (1)Stability review 3: Jan 27 -2015

Project release consolidation

Definition of done: Released stable system including documentation, repeatably working ci-pipeline, repeatably passing fun-test, a 48 hours of stability test, release notes with documented deviations.

Due date: Feb 2 -2016

(1): Stability review is referred to as the process where the fuel committers review the actual system stability and decides upon corrective actions. Corrective actions could be any of:

  • Gating commits to the stable branch
  • Assigning a task-force team to perform system stabelization activities/measures
  • Deciding to push a features not enough stable/not meeting enough test coverage to a next release.

Feature owners/PTLs of integrated projects are expected to participate in the stability reviews, but lack voting rights in case voting is needed.

fuel_opnfv_b-wp.1446402542.txt.gz · Last modified: 2015/11/01 18:29 by Jonas Bjurel