Page tree
Skip to end of metadata
Go to start of metadata

Brahmaputra release plan

IRC: Freenode #opnfv-release

Meeting Logistics

NOTE: As we approach release we are holding daily standup meetings with key stakeholders via irc.
Logistics: IRC channel #opnfv-release
Time: 6:00 am PDT, Mon-Fri
Daily status

Americas/Europe Release Team Meeting:

    Tuesdays 8am Pacific 
    GoToMeeting Meeting ID: 341-956-909 
    IRC freenode #opnfv-meeting

APAC Release Team Meeting:

    Wednesdays 10am Beijing 
    GoToMeeting Meeting ID: 788-853-365 (Updated on October 20) 
    IRC freenode #opnfv-meeting

Meeting Minutes

Current Jira Dashboards:

Brahmaputra Overall Status

Brahmaputra Project Specific Status: Apex - Doctor

Brahmaputra Project Specific Status: Escalator - Movie

Brahmaputra Project Specific Status: Multisite - Pharos

Brahmaputra Project Specific Status: PolicyTest - Resolved

Brahmaputra Project Specific Status: StorPerf - Yardstick

Brahmaputra Project Specific Status: ONOSFW

Weekly Project Status Updates (prior to Jira)


This is a Release Plan for the Brahmaputra release of OPNFV. This is the second release of OPNFV and the first iteration of a simultaneous cross community release plan.

Please read carefully to understand the requirements to participate and for each milestone. Projects may choose to participate or not based upon their readiness and desire to join the Simultaneous Release.

In July the OPNFV Board gave the following direction for the OPNFV Brahmaputra release:

Scope: Brahmaputra Release Theme: “Lab Ready Release”

  • Minimum base functionality to make a lab “usable”
  • Gave us a ‘non-exclusive” set of project functionality
  • High level so as to allow us flexibility
  • We define details of what “Lab Ready” means

Schedule: 6 months, tied to OpenStack

  • We gave feedback that OpenStack is not our only external dependency


Brahmaputra Release Planning slides presented at July 2015 Hackfest

(NOTE: schedule & scope presented in these are not approved by TSC at this time) hackfest-breleaseplanning150730.pdfJuly 2015 Hackfest Community Definition of "Lab Ready"(all participating projects should strive for this level or above)NOTE: not approved by TSC yet*

  • Reliable, repeatable installer
  • Two agreed upon network configurations
  • Installable artifacts
  • Continuous Integration
  • Documentation:
    • minimum requirements
    • list of required software & suggested hardware
    • description of lab setup
    • list of basic skills required
    • Pharos: description of the test lab, tooling, & scheduling processes
    • API description
    • FAQ
  • Logs for troubleshooting
  • Tutorials & training
  • Sample test/scenarios
  • Support mechanism (staffed)
  • Release notes
  • Bug tracking

Milestone Definitions

Milestone A - statement of intent Brahmaputra Release participation. To join the release after this milestone projects must have completed milestone B deliverables.

Milestone B - Per project plan for the Brahmaputra Release
Features and dependencies identified in Jira
If a project wishes to join between this milestone & milestone C they must go through an “exception” process and demonstrate that they have completed the requirements of milestones B & C at the time of request, as well as demonstrate that they have the ability to meet all future milestones

Milestone C - First Sprint planning ready (critical Jira tasks written); general Sprint planning completed and in Jira (i.e. how many Sprints (and/or Epics) you plan to have, duration of Sprints, themes for each Epic/Sprint)
Requirements projects: All upstream requirements published
Deploy toolchains: All integrated components identified and planned
Testing projects: All features identified and test specifications ready
Infrastructure projects: All dependencies identified and planned
Project entry freeze. No projects will be accepted into the release after this milestone.

Milestone D - Feature and API freeze

Milestone E - Code freeze - documentation complete
Requirements projects: Upstream development complete
Deploy toolchains: Integration features complete
Testing projects: Test cases complete

Begin release candidate and release activities

Milestone F - Brahmaputra Release


Approved by TSC on Aug 18, 2015





Aug 18

All projects have provided an "intent to participate" communication


Aug 18

Each participating project has completed their initial planning phase with features and dependencies identified in Jira. Note: If a new project wishes to join between this milestone & milestone C they must go through an “exception” process and demonstrate that they have completed the requirements of this & all previous milestones as well as that they have the ability to meet all future milestones


Sep 25

First Sprint planning ready (critical Jira tasks written); general Sprint planning completed and in Jira (i.e. how many Sprints (and/or Epics) you plan to have, duration of Sprints, themes for each Epic/Sprint)Requirements projects: All upstream requirements published Deploy toolchains: All integrated components identified and planned Testing projects: All features identified and test specifications ready Infrastructure projects: All dependencies identified and planned Project entry freeze: No new projects will be accepted into the Brahmaputra release after this milestone


Dec 1

Feature and API freeze: no new features or APIs will be accepted beyond this milestone
Milestone D report


Jan 5 achieved Jan 29

Code freeze: documentation complete and submitted Requirements projects: Upstream development complete Deploy toolchains: Integration features complete Testing projects: Test cases complete

Target Release Date

Feb 26, 2016

Target Release: Release Candidates and Release activities

Target Stable Release 1

Mar 25, 2016

Target release: for current content that has not reached stable by Feb 26

Participating Projects


Brahmaputra Release Participating Projects



scope notes

dependency notes



Tim Rozet, Dan Radez

improved OPNFV Installer which incorporates requirements set by Genesis Apex Milestone C Report Apex Milestone D Report Apex Milestone E Report

upstream tools (RDO Manager, OpenStack, OpenDaylight, other SDN controllers). We also depend on OPNFV projects like Octopus for build + CI verification, functest for functionality verification.


Armband Armband did not make code freeze so will move to C release

Bob Monkman

enable ARM processor support in OPNFV Armband Milestone C Report ARMband Milestone D Report ARMband Milestone E Report




Hongbo Tian

automatically test framework, methodology, test cases, experiments results and analysis of results Bottlenecks Milestone C Report Bottlenecks Milestone D Report Bottlenecks Milestone E Report

openstack ODL KVM and OVS



Weidong Shao

installer project in Genesis; intends to deliver installer in R2 Compass4nfv Milestone C Report Compass4nfv Milestone D Report Compass4nfv Milestone E Report

upstream project releases, Compass 2.0 readiness in the given time frame, Genesis project


Connectivity Services LSO (LSOAPI) at high risk for B-Release

Kevin Luehrs

Provides interface to OpenDaylight, exposing capabilities of ODL to provision Carrier Ethernet services in network elements LSOAPI Milestone C Report LSOAPI Milestone D Report LSOAPI Milestone E Report

OVSDB Southbound API, yangtools


Copper at high risk for B-Release

Bryan Sullivan

1. Analysis of VIMs abilities to configure/govern NFVI resources 2. blueprints to fill gaps Copper Milestone C Report Copper Milestone D Report Copper Milestone E Report

access to a testbed, & ability to augment it with additional VIM releases/components (OpenStack Kilo or Liberty, ODL Lithium, and OpenStack Congress).


Doctor at high risk for B-Release

Ryota Mibu

1. Upstream Development (Ceilometer event-alarm, Nova mark-host-down) 2. User Manual 3. Requirement Document (update architecture; evaluate integration of other monitoring tools; extended gap analysis) Doctor Milestone C Report Doctor Milestone D Report Doctor Milestone E Report

OpenStack Liberty (Nova, Ceilometer/Aodh) which includes features we developed. Integration of other monitoring tools has some dependency on the interfaces available for those tools. For the other tasks, currently no dependencies are known



Lingli Deng

DPACC Milestone C Report DPACC Milestone D Report DPACC Milestone E Report




Jie Hu

Smooth upgrade; Requirement Document, a first version of Gap Analysis Report (will evolve over time), and maybe some additional documents for developer. Escalator Milestone C Report Escalator Milestone D Report Escalator Milestone E Report

We need two working OPNFV releases for comparison and try to find a generic way for smooth upgrade. And we will collect special upgrade requirements from other projects, like Doctor, HA, Multi-Site, etc.



Jonas Bjurel

Continuation of Arno BGS; fuel upstream OPNFV & ODL integrated installer Fuel_OPNFV Milestone C Report Fuel Milestone D Report Fuel Milestone E Report

We cannot freeze code before a stable release candidate of Fuel 8.0 has been cut, We cannot release Fuel@OPNFV before a stable Fuel 8.0 release, We cannot codefreeze before the selected service release of OpenDaylight Lithium have been released. Fuel upstream is obviously dependent of the OpenStack release schedule. In order to be able to do a fair planning we will need to develop end-state definition/use-cases and definition of done within the Genesis project



Morgan Richomme; Jose Lausuch

completion of the existing tests (we got error in R1, we should try to have less even if most of the errors are due to bugs in upstream projects (as documented in functest guide for Arno =>

), work on a cartography for coverage => web/wiki page, work on a cartography for coverage => web/wiki page, work on analytics to exploit existing results => setup of NoSQL DB + first analytics script + Testcase dashboard (web pages), work on a portal to reference testcases and automatically generated the list of testcases => IT tool + scripts => generate html/pdf (as guide) Functest Milestone C Report Functest Milestone D Report Functest Milestone E Report

API/DB results collection: need DB to store results pharos: need an API to collect information of the different POD we are performing the tests (hardware, tooling,) needed for analytics releng need the NoSQL DB facilities and automation script other testing projects (yardstick, vperf) we will need strong cooperation with them and everything has to use the same framework to provide results that we are designing, automation of a vIMS testcase Bitergia dashboard for results SFC Project: test case & collaboration Policy: test case Other SDN Controllers: test cases & collaboration



Frank Brockners

Requirements for deployment tools ("installers") Genesis Milestone C Report Genesis Milestone D Report Genesis Milestone E Report

Apex, Fuel, JOID, Compass4nfv, OpenSteak



Fu Qiao

HA requirement doc; scenario analysis doc.for later releases: gap analysis; deployment guide; HA API HA Milestone C Report HA Milestone D Report HA Milestone E Report

No dependency as far as we know for release B; dependent on OpenStack and ETSI NFV for long term deliverables



Bin Hu

Use Case and Requirement Gap Analysis IPv6-enabled OPNFV ISO Documentation Optionally, Test Methodology if any Ipv6 Milestone C Report IPv6 Milestone D Report IPv6 Milestone E Report

Multisite IPv6 Community labs and Testbed with CI integration Developer resources to accelerate implementation and enhancement, Test resources to define test methodology and develop test cases if any



Artur Tyloch, Narinder Gupta

OPNFV installer with multiple options for components deployment (e.g. SDN); detailed planning in progress JOID Milestone C Report JOID Milestone D Report JOID Milestone E Report

Octopus (integration with OPNFV CI infrastructure) and Pharos (to ensure we have POD resources allocated to test various configuration options).



Ruan HE

Moon Milestone C Report Moon Milestone D Report Moon Milestone E Report

Targeting D release for code



Tianran Zhou

Architecture and API Spec; code could be delivered in later release- at risk due to dependency Movie Milestone C Report Movie Milestone D Report Movie Milestone E Report

OpenStack experimental Micro API and currently it's independent of releases and should be in Liberty for allowing API versioning



Joe Huang

use cases, requirements, & gap analysis at minimum; spec & code approval Multisite Milestone C Report Multisite Milestone D Report Multisite Milestone E Report

none for release B (requirements development only; for later release of code then dependent on OpenStack M release



Don Dugger

provide enhancements for interrupt latency variation, inter VM communication and live migration. NFV for KVM Milestone C Report NFV for KVM Milestone D Report NFV for KVM Milestone E Report

Our biggest dependency right now is getting the detailed planning/engineering timeline created.


Octopus (Continuous Integration)

Uli (Ulrich) Kleber

improved CI pipeline; documentation Octopus Milestone C Report Octopus Milestone D ReportOctopus Milestone E Report

no details know at this point



Ash (Ashlee) Young

ONOS SDN Controller; Suricata DPI; Neutron ML2 plugin; Neutron ML3 plugin; Compass installer, JOID installer, Fuel installer, Apex installer, SFC support, Other framework APIs ONOSFW Milestone C Report ONOSFW Milestone D Report ONOSFW Milestone E Report

ONOSFW is already an upstream project relative to OPNFV, hence we have our own integration, patch management, and mechanisms for cooperating with other related projects. ONOS: Emu release


Open vSwitch for NFV

Mark D. Gray

Enable Userspace Open vSwitch as a configurable deployment option Open vSwitch for NFV Milestone C Report OVSNFV Milestone D Report OVSNFV Milestone E Report

Our biggest dependency right now is getting the detailed planning/engineering timeline created



Chris Price

Infrastructure & Support; Documentation Process Definitions; geric documents opnfvdocs Milestone C Report OPNFV Docs Milestone D Report OPNFV Docs Milestone E Report




Stuart Mackie

OVNO Milestone C Report OVNO Milestone D Report OVNO Milestone E Report




Howard (Zhipeng Huang)

provide a tool to translate from YANG to TOSCA or TOSCA to HOT Parser Milestone C Report Parser Milestone D Report Parser Milestone E Report

heat-translator, (ETSI/NFV, TOSCA-NFV spec, not mandatory, just used for referrence of required features)


Pharos Home

Trevor Cooper

Deliver additional/enhanced deployment and test infrastructure capabilities for developers and CI. -Linux Foundation infrastructure usage and support process -Rev B of Pharos specification -Pharos compliant lab requirements / definition -Infrastructure management tools -Environment and deployment templates -Dashboards for tracking community labs capability, availability, utilization Pharos Colorado Plan Pharos Milestone D Report Pharos Milestone E Report

 Project Requirements on Pharos


PolicyTest No longer part of B-release

Keith Burns

Policy related tests for OPNFV Policy Test Milestone C Report Policy Test Milestone D Report Policy Test Milestone E Report

FuncTest, Yardstick, Octopus, Releng



Hai Liu

use case, gaps & corresponding predictor code Prediction Milestone C Report Prediction Milestone D Report Prediction Milestone E Report




Peter Lee

1. An updated requirements document to address following areas: * Allocation messaging flow and related information elements utilizing reservation context * Reservation scope clarifications (complete NFVI vs. tenancy) (reconcile with ETSI) * Implicit reservation reference during allocation (reconcile with ETSI) 2. Working reference implementation demo * Querying available capacity * Reserving a resource for future use * Allocating a previously reserved resource" Promise Milestone C Report Promise Milestone D ReportPromise Milestone E Report

1. Identification of NFVI community lab requirements 2. Developer resources for accelerating implementation



Wenjing Chu

A Benchmarking suite for Bottoms up testing for NFVI platforms; currently gathering requirements Qtip Milestone C Report Qtip Milestone D Report Qtip Milestone E Report

Pharos, BGS



Fatih Degirmenci

automation, tooling, and sw development infrastructure support; at the early phases of our planning and the details will become available during August. Tooling/automation for test result reporting/storage/analytics, development and deployment of common scripts and jenkins jobs, identification of release process, improved document generation automation and toolchain, creating corresponding documentation Releng Milestone C Report Releng Milestone D Report Releng Milestone E Report

installer projects, test projects, octopus, and LF in order to develop/install/deploy needed automation/tooling (DB, webserver, etc.)


Resource Scheduler Home

Rex (Liming Jiang)

plan to create req documentation in R2 RS Milestone C Report RS Milestone D Report RS Milestone E Report

none for B release (requirements phase); with code in future release: OpenStack



Tim Irnich

SDNVPN Milestone C Report SDNVPN Milestone D Report SDNVPN Milestone E Report



Service Function Chaining (SFC)

Brady Johnson

minimal Service Chaining solution based on ODL & SFC project in NFV environment SFC Milestone C Report SFC Milestone D Report SFC Milestone E Report

Upstream dependencies OVS ODL SFC OpenStack 1. OpenDaylight Beryllium release - We’ll be building nightly Beryllium snapshots, but need to release with the final release - We will be using at least the following ODL sub-projects: .Service Function Chaining .Neutron Northbound .Group Based Policy .Open vSwitch DataBase (OVSDB) .OpenFlow Plugin 2. Open vSwitch with NSH support -Cisco has branched OVS and created an NSH (NW Services Hdr) patch, but it hasn’t been formally accepted yet. -Still waiting for info on version details, either 2.4.X or 2.5. (Should know by Aug 12) 3. OpenStack -No specific dependencies on overall project, should be ok with Kilo release. -We plan to use the latest OpenStack Tacker sub-project, but Im not sure yet about versions, etc 4. OPNFV -No specific dependencies identified yet.



Maryam Tahham

DPDK Keep Alive Sample App on Guest (A simple forwarding app with DPDK KA functionality): Extend a collectd plugin to OpenStack that exposes DPDK statistics to Ceilometer. Provide a DPDK Keep alive feature, this feature facilitates support for failover of DPDK enabled cores. The 2 features provided for release B will be a collectd plugin for DPDK + a DPDK feature to facilitate support for failover of DPDK enabled cores SFQM Milestone C Report SFQM Milestone D Report SFQM Milestone E Report

DPDK 2.2 (November 30th 2015) and colletd plugin to OpenStack



Edgar StPierre / Mark Beierl

StorePerf Milestone C Report StorPerf Milestone D Report StorPerf Milestone E Report




Cathy Zhang

Architecture and API Spec; code could be delivered in later release- at risk due to dependency VNFGraph Milestone C Report VNFGraph Milestone D Report VNFGraph Milestone E Report

inbound: OpenStack Liberty



Maryam Tahhan

Python based vSwitch performance test framework: This framework will include RFC2544 performance tests for Open vSwitch DPDK and Vanilla OVS with a range of traffic generators for the following deployment scenario Physical port to Physical port and Physical port to VNF to Physical port. The Framework is what’s intended to be released as part of release B VSPERF Milestone C Report VSPERF Milestone D Report VSPERF Milestone E Report

VSPERF: dependency POD3 HW availability in Intel Lab in HF



Ana Cunha

6 epics identified & in jira Yardstick Planned Epics:

Yardstick Milestone C Report Yardstick Milestone D Report Yardstick Milestone E Report

    • Genesis:* the installers that are part of Genesis are deployed and there exists an environment for Yardstick framework and test cases to be verified against - Pharos: provide lab infrastructure for deploying and executing the Yardstick framework and test cases; provide lab infrastructure for deploying VNF VTC which is part of Yardstick Project - Releng: automation, database for storage of results - Other projects: as a testing Project, Yardstick provides a framework and a set of generic test cases for VNFI (compute, storage and networking) verification from VNF perspective; it can also help other projects to execute the test cases Generally, Yardstick depends on: Definition of SLA/KPI for OPNFV infrastructure test cases is needed to execute and collect results of OPNFV test cases; Test cases requirements from OPNFV Projects (Service Function Chaining and NFV Hypervisors- KVM and possibly others are needed for completing related Epics); Genesis (Installers, credentials for accessing infra-structure details are needed for executing the tests) Pharos (POD infrastructure specification is needed for executing the tests) Releng (automation, database for result storage are needed for automation of test cases), Common test topics (templates for test cases, API for result storage)












Brahmaputra Project Box

Base Plan

Installer Projects
  • Apex: improved OPNFV Installer
  • Compass4nfv: installer
  • Fuel: installer
  • Genesis:
  • JOID: multiple components installer
  • OpenSteak: automated setup for Genesis
Test Projects
  • Functest: complete Arno tests
  • Yardstick: Infrastructure verification method, from VNF perspective developed; Infrastructure verification, framework developed & tested
Infrastructure Projects
  • Octopus: Improved CI pipeline
  • OPNFV Docs: infrastructure & support
  • Releng: automation, tooling, and sw development infrastructure support.
  • ONOSFW: ONOS SDN Controller; Neutron ML2 plugin; Neutron ML3 plugin; Compass installer, Fuel installer, JuJu installer, Apex installer, Service Function Chaining (SFC) support.
  • HA: API
  • Parser: translation tool
  • Prediction: use case, gaps, & corresponding code
  • SFC: minimum Service Chaining solution
  • VNFFG: architecture & API spec, code
  • NFV for KVM: provide enhancements for interrupt latency variation, inter VM communication and live migration.
  • Doctor: features implemented/ing in the upstream (Mark Host Down API in Nova and Event Alarm in Ceilometer), and corresponding user manuals

Working Plan

(we are working as if these are in base plan but either they are not mandatory or they have some small risk of delivery with a work around. We would release without them if they were not ready in time)

Test Projects
  • Bottlenecks: automatic test infrastructure, methodology, framework developed
  • Functest: additional test coverage & documentation
  • QTIP: Benchmarking suite
  • VSPerf: base framework for benchmarking the performance of a virtual switch
Infrastructure Projects
  • Octopus: documentation
  • OPNFV docs: Documentation Process Definitions; geric documents
  • Pharos:
Requirements Projects
  • Copper: gap analysis & blueprints
  • Doctor: gap analysis & documentation
  • Escalator: gap analysis & requirements documented
  • HA: gap analysis & requirements
  • Multisite: req’s doc
  • Open vSwitch for NFV Enable Userspace Open vSwitch as a configurable deployment option
  • Resource Scheduler: requirements document
  • Transformer: requirements document
  • Connectivity Services LSO [lsoapi]: 3 Ethernet Services APIs
  • Promise: updated requirements document; demo developed
  • IPV6: gaps analysis, requirements, working reference implementation demo
  • SFQM SFQM: collectd plugin for DPDK + a DPDK feature
  • MOVIE: Document experimental API for Node, Link, Path and 3 node Cluster topology for Jury
C&D Projects
  • ONOSFW: ONOS SDN controller, Suricata DPI, Auditd, SFC functionality,
  • Jury: Intent Based Policy (IBP) add-on to MOVIE API as an upstream or an OPNFV project

At Risk

(these are at significant risk and may not make this release)

  • Multisite: specs and code approval


(the team will not expend energy on these, they may be planned for a later release)


Please use the example as shown for VSPERF project: VSwitch Release Plan

Labels in JIRA help to sort issues by release target and milestones:

  • R2 = Release 2 = Brahmaputra
  • R2MC = Release 2 Brahmaputra Milestone C

A JIRA issue can have multiple labels. The more details you provide the better quality our reports will be.

  • No labels