OPNFV SFQM Brahmaputra

Slides:



Advertisements
Similar presentations
Test plans. Test Plans A test plan states: What the items to be tested are At what level they will be tested What sequence they are to be tested in How.
Advertisements

Agile Planning Dealing with Reality. Reality Basic agile principle – don’t expect static plans to hold, be flexible and expect changes.
Janet Scalese Rachel Sanderoff TTB Nonbeverage Products Lab
Coherent Web Sustaining Engineering Plan 1. The Coherent Web team will: Utilize two-week development “sprints” to plan and track implementation activities.
Configuration Management Managing Change. Points to Ponder Which is more important?  stability  progress Why is change potentially dangerous?
1 Copyright © 2013 Kony Inc. CONFIDENTIAL 1 iOS 7 : Kony Platform Compatibility Date: 26-Aug-2013.
1 Test Planning CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 9, 2007.
Using Statistics in Research Psych 231: Research Methods in Psychology.
Chapter 15 Design, Coding, and Testing. Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Document The next step in the Software.
1 DRAFT CCC Team Leader Packet September 23, 2002.
(c) 2007 Mauro Pezzè & Michal Young Ch 24, slide 1 Documenting Analysis and Test.
Upcoming Ecolane Implementations and Software Enhancements
Software Configuration Management
1 Doctor Fault Management 18 May 2015 Ryota Mibu, NEC.
SAIC-F QA Internal Process (DRAFT ) Sudha Chudamani QA Team, Frederick National Lab Jan 2, 2013.
Managing Projects and Clients Senior Consultant Training 23 September 2005.
EPayment ePayment Introduction It is the process of electronic transfer of bill data between booking and payment office Department of Post collects.
Case Submittal Best Practice
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
1 Doctor Fault Management - Updates - 30 July 2015 Ryota Mibu, NEC.
Software Project Planning CS470. What is Planning? Phases of a project can be mostly predicted Planning is the process of estimating the time and resources.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
242/102/49 0/51/59 181/172/166 Primary colors 248/152/29 PMS 172 PMS 137 PMS 546 PMS /206/ /227/ /129/123 Secondary colors 114/181/204.
Software Development Process and Management (or how to be officious and unpopular)
Monthly Updates to Presort Data. Agenda What is Presort Data? History of Update Schedule Important Terms to Understand The New Schedule Transition to.
EGEE is a project funded by the European Union under contract IST Testing processes Leanne Guy Testing activity manager JRA1 All hands meeting,
Monitor & Control Risks 1 MEC-4. What is Monitoring & Controlling Risks? 2 » Monitoring & Controlling Risks is the process of: implementing Risk Response.
4.4 Timeline for M2M Consolidation Susan Miller ATIS Head of Delegation Meeting of Potential M2M Consolidation Partners #2 Washington, D.C. August 17-18,
NMI End-to-End Diagnostic Advisory Group BoF Fall 2003 Internet2 Member Meeting.
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
CSCI 521 Final Exam Review. Why Establish a Standard Process? It is nearly impossible to have a high quality product without a high quality process. Standard.
Targets for project progress 2015: graduation review – clear documentation and PoC implementation specify general framework and API requirements gap analysis.
Rational Unified Process (RUP) Process Meta-model Inception Phase These notes adopted and slightly modified from “RUP Made Easy”, provided by the IBM Academic.
Chair of Software Engineering Exercise Session 6: V & V Software Engineering Prof. Dr. Bertrand Meyer March–June 2007.
Grid Security Vulnerability Group Linda Cornwall, GDB, CERN 7 th September 2005
DEX Publication Project OASIS PLCS Telecon 27 November 2007 Trine Hansen.
SCORM Status. 2 Stabilization, Clarification and Issue Resolution Bug Fixes, Corrections & Clarifications SCORM 2004 January 2004 SCORM nd Edition.
Project management Topic 7 Controls. What is a control? Decision making activities – Planning – Monitor progress – Compare achievement with plan – Detect.
Test status report Test status report is important to track the important project issues, accomplishments of the projects, pending work and milestone analysis(
DEX Publication Project OASIS PLCS TC Telecon 22 January 2008 Trine Hansen.
Monitor & Control Risks 1 MEC-4. What is Monitoring & Controlling Risks? 2 » Monitoring & Controlling Risks is the process of: implementing Risk Response.
August 25, 2008 TPTF Nodal Status Report: Integrated Schedule Update Change Control Update Adam Martinez Troy Anderson.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 Phase Testing. Janice Regan, For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine.
Mathias DEPRETZ – EuroVO-DCA Project Manager Work Package 1 – Management First Board Meeting – 2&3 october 2006 WP1 Management EuroVO-DCA Project FIRST.
Week # 4 Quality Assurance Software Quality Engineering 1.
05 October 2010 HMA-FO Task 2: Feasibility Analysis Service HMA Follow On Activities Task 2: Feasibility Analysis Service (Sensor Planning Service) Monthly.
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
Slide 3.1 © The McGraw-Hill Companies, 2002 SOFTWARE LIFE-CYCLE MODELS.
OPNFV VSPERF Brahmaputra Release Planning Maryam Tahhan August
**DRAFT** Doctor+Congress OPNFV Summit June 2016 Doctor+Congress PoC team.
Introduction to CAST Technical Support
Collectd 101.
Collectd 101.
Nodal Status Report: Program Controls Update
2nd Plugfest Kickoff July 18, 2016.
Tomi Juvonen SW Architect, Nokia
SQL Server BI on Windows Azure Virtual Machines
SQL Server OLTP with Microsoft Azure Virtual Machines
Teaching slides Chapter 1.
This presentation document has been prepared by Vault Intelligence Limited (“Vault") and is intended for off line demonstration, presentation and educational.
Introduction to CAST Technical Support
Figure 3: Risk Analysis Model
Coordinate Operations Standard
Project Progress Summary - Week 18
Project Overview.
Desktop App Assure Service Microsoft Representative Name June 7, 2019
Proposal on TSC policy for ONAP release Maintenance
Presentation transcript:

OPNFV SFQM Brahmaputra Release Planning Maryam Tahhan August 09 2015

Project Box Minimum viable requirements Want but at risk requirements Detailed Requirements in later slides Minimum viable requirements (Cant release without these) DPDK Keep Alive Sample application DPDK NIC stats extensions: i40e and VF stats. Want but at risk requirements (Like to have, but high risk) Working plan requirements (Minimum Viable, low risk, but high effort needed) CollectD DPDK stats Plugin Outplan requirements (Future requirements not in this release.)

Risks Assessment Description Likelihood Impact Trigger Mitigation Contingency Owner Status DPDK Keep Alive Sample application High Low DPDK KA app testing fails Work with DPDK upstream Don't release DPDK KA Maryam Ongoing DPDK NIC stats extensions: i40e and VF stats DPDK NIC stats testing fails Don't release DPDK i40e or VF stats CollectD DPDK stats Plugin low CollectD testing fails Work with CollectD upstream Don't upstream CollectD plugin Impact Likelihood We care about these Low-Low High-Low High-High Low-High

Minimal Viable Detailed Requirements Taken from the “Project Box” on previous slides The OPNFV SFQM Brahmaputra Release cannot release without these: DPDK Stats Extensions Deliverables: IXGBE error/extended stats Exposure i40e error/extended stats Exposure Sample App that retrieves stats on the Host Sample App that retrieves stats on the Guest Sample App that retrieves Host stats on the Host Description: Development activity to support the exposure of NIC MAC/PHY Level Counters, particularly for packet drops and errors. Functional Requirements: Expose error/drop registers to DPDK Sample Apps Expose VF including error/drop registers to DPDK Sample Apps Extend Exposed registers to include those not in struct hw_stats Extend Exposed registers to include Sums that are not in struct hw_stats Performance Requirements: Does NOT impact performance. Targeted DPDK release: DPDK 2.1 and DPDK 2.2 (November 30th 2015) Notice: This is still a draft

Minimal Viable Detailed Requirements cont Taken from the “Project Box” on previous slides The OPNFV SFQM Brahmaputra Release cannot release without these: DPDK Stats Extensions Status: Feature Expose error/drop registers Expose VF registers Expose additional registers Expose totals registers IXGBE DPDK 2.1(DONE) DPDK 2.2 i40e Sample App on Host/Guest N/A Sample App on Guest for Host stats Notice: This is still a draft DPDK 2.2 == In Progress

Minimal Viable Detailed Requirements Taken from the “Project Box” on previous slides The OPNFV SFQM Brahmaputra Release cannot release without these: CollectD DPDK stats Plugin Deliverable: CollectD Plugin for DPDK stats Description: CollectD Plugin that runs on the host and polls stats from DPDK Functional Requirements: Runs on the Guest/Host. Collects PF/VF Stats. Performance Requirements: Does NOT impact performance. Targeted DPDK release: upstream to github by the end of October as there is no release cadence for CollectD. Status: To be started. Notice: This is still a draft

Minimal Viable Detailed Requirements Taken from the “Project Box” on previous slides The OPNFV SFQM Brahmaputra Release cannot release without these: FEATURE: DPDK KEEP ALIVE (KA) Deliverable: DPDK Keep Alive Sample App on Guest (A simple forwarding app with DPDK KA functionality) Description: Development activity to support detection of ‘failed’ DPDK cores and notification to a HA/SA middleware. The purpose is to detect Packet Processing Core fails (e.g. infinite loop) and ensure the failure of the core does not result in a fault that is not detectable by a management entity. Functional Requirements: Runs on the Guest. Runs on the Host. Configurable timeouts. Measures detection time. Has a hook function where HA/SA middleware can hook in for fault management notifications. Performance Requirements: Does NOT impact performance. Targeted DPDK release: DPDK 2.2 (November 30th 2015) Status: In Progress Notice: This is still a draft

Preliminary Dependencies This is a preliminary list of the OPNFV SFQM dependencies. Later, I’ll create a Milestone timeline for better visibility. DPDK CollectD

SFQM High level Milestone Schedule Mid/End October 2015 Mid November 2015 Dependencies - DPDK - CollectD WW = Work Week DPDK Week … X-11 X-10 X-9 X-8 X-7 X-6 X-5 X-4 X-3 X-2 X-1 X WW37 WW38 WW39 WW40 WW41 WW42 WW43 WW45 WW46 WW47 WW48 WW49   Patches for the new release are developed and submitted to the mailing list. Features to be developed include: DPDK Keep Alive, DPDK extended stats features and CollectD plugin for DPDK statistics Community review, testing and rework of patches. No new patches submitted during this time. Patches without open issues applied Testing of Release Candidate 1 and subsequent RCs. Bug Fixing Testing of final RC. Only fixes to high priority bugs accepted during this time Final Version of all patches submitted to mailing list for review Final Verision of all patches applied, RC1 built Final RC built Release available: DPDK Keepalive and DPDK extended stats features are part of DPDK 2.2 Additional RCs as Required CollectD release Schedule is unknown, There doesn't seem to be a standard release cadence. Plan is to have collectD DPDK plugin pushed to github/upstreamed by the end of October End of November 2015 End of Sept 2015