releases:brahmaputra:release_plan
Table of Contents
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
Current Jira Dashboards:
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
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
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
