User Tools

Site Tools


releases:brahmaputra:release_plan

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:

Introduction

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.pdf

July 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

Schedule

Approved by TSC on Aug 18, 2015

Milestone Date Events
A Aug 18 All projects have provided an "intent to participate" communication
B 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
C 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
D Dec 1 Feature and API freeze: no new features or APIs will be accepted beyond this milestone
Milestone D report
E 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

Project Lead scope notes dependency notes
Apex 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
Bottlenecks 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
Compass4nfv 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
DPACC Lingli Deng DPACC Milestone C Report DPACC Milestone D Report DPACC Milestone E Report
Escalator 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.
Fuel 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
Functest 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 ⇒http://artifacts.opnfv.org/functest/866/docs/functest.html), 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
Genesis Frank Brockners Requirements for deployment tools ("installers") Genesis Milestone C Report Genesis Milestone D Report Genesis Milestone E Report Apex, Fuel, JOID, Compass4nfv, OpenSteak
HA 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
Ipv6 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
JOID 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).
Moon Ruan HE Moon Milestone C Report Moon Milestone D Report Moon Milestone E Report Targeting D release for code
Movie 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
Multisite 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
NFV for KVM 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 Report Octopus Milestone E Report no details know at this point
ONOSFW 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
opnfvdocs Chris Price Infrastructure & Support; Documentation Process Definitions; geric documents opnfvdocs Milestone C Report OPNFV Docs Milestone D Report OPNFV Docs Milestone E Report
OVNO Stuart Mackie OVNO Milestone C Report OVNO Milestone D Report OVNO Milestone E Report
Parser 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 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 Milestone C Report 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
Prediction Hai Liu use case, gaps & corresponding predictor code Prediction Milestone C Report Prediction Milestone D Report Prediction Milestone E Report OpenStack
Promise 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 Report Promise Milestone E Report 1. Identification of NFVI community lab requirements 2. Developer resources for accelerating implementation
Qtip 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
Releng 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 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
SDNVPN 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.
SFQM 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
StorPerf Edgar StPierre / Mark Beierl StorePerf Milestone C Report StorPerf Milestone D Report StorPerf Milestone E Report
VNFFG 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
VSPerf 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
Yardstick Ana Cunha 6 epics identified & in jira Yardstick Planned Epics: https://wiki.opnfv.org/sprints 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.
Features
  • 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

Outplan

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

JIRA ISSUE LABELS

Please use the example as shown for VSPERF project: https://wiki.opnfv.org/wiki/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.

releases/brahmaputra/release_plan.txt · Last modified: 2016/02/09 16:41 by Debra Scott