Date

05 Nov 2020

Attendees

• Jim Baker Heather Kirksey  Scot Steele  Beth Cohen Al Morton David McBride Qiao Fu  Toshiyasu Wakayama Ulrich Kleber Georg Kunz Trevor Cooper William Diego Maza Jonne Soininen Lincoln Lavoie Ildiko Vancsa  sunku ranganath Phil Robb Tom Van Pelt

Discussion items

Notes

Interim TSC plans

• OPNFV providing 8 members from the seated TSC as selected by the active community members
• CNTT will wait for completion of the OPNFV proposed interim TSC membership
  • Look for equitable distribution of seats between operators and vendors for Anuket TSC
• This is for a INTERIM TSC ONLY - not a permanent change

Business Coordination Function

• Expect a short term function - up to two years. Can continue as needed.
• Volunteer staffed - likely to be the same folks that are staffing the Anuket MeldMarketing 
• Focused on the initial project spin-up. Eventually absorbed by MAC function
• Trevor Cooper Please write down the scope and responsibility of this function
  • CNTT equates Governance to Business Coordination
• Notes from Scot Steele
  • Strategy, Participant interface; On-boarding, escalation point for complex, inter-related issues; Virtual Conference mgmt, other Admin tasks, Coordination with other projects, Recruitment

Release Process and Naming

• Key problem statement: How do we use naming to unify the specification versions with subsequent releases of the RC?
• Georg Kunz Joint release planning between the spec developers and the RC developers could address this.
• Trevor Cooper It's dependency management. 
  • RC project does not equal the OVP program
    • RC develops test cases and tools to test RA requirements - unlikely to ever deliver 100% of the requirements - MUST be decoupling and independent projects
• Lincoln Lavoie RC is a work stream of individual projects - not a single entity
  • Perhaps RC should handle the traceability and coverage mapping - by definition it will lag the specification version
  • What is the stated goal of the lag?
  • The specifications are a monotonically increasing list (moving target)
  • RC may not always track the increase in feature sets
• David McBride  propose decoupling of specification and RC releases
  • Likewise use different naming to avoid assumptions of RC fulling implementing a specific RA version
• Lincoln Lavoie RA/RM release Q1 and Q3, RI/RC release on Q2 and Q4
  • 4 releases per year: 2 spec focused and 2 test focused
  • RC must provide 100% coverage of RI - for whatever features that are implemented in the RI
• Georg Kunz There will always be a gap/offset
• Heather Kirksey Could create a longer release process that just makes the spec a milestone in a longer release cycle. 
• Al Morton  Community is asking for more synchronized processes
  • 3 month is not sufficient for developing response to the specifications - far shorter than prior OPNFV releases
  • Possibly overlap the last 3 months of spec dev with first 3 months testing development
• David McBride Concern is development of specifications will outpace the development of tests
• Jim Baker  FOCUS is first 3 months of 2021

Role of Installers

• Trevor Cooper Role of installers has been an issue in the history of OPNFV
  • Proposed statement: Installers are NOT a part of a release. They are a tool to create an RI
  • OPNFV Jerma has one installer: Airship - it is unclear that this installer meets all the needs of the community
• Georg Kunz Installers may be released as a part of "RI"
  • How many installers and sets of components (RIs) does Anuket want to support?
    • Would prefer ONE RI to pool resources
• Trevor Cooper Airship project is a stand-alone tool - it doesn't deliver a RI
  • RI is delivered as a cookbook or method for deploying the RI
• Georg Kunz Would like to use an RI in the internal testing process for commercial xNFs
• Trevor Cooper Propose deferring the decision to the Release Artifacts discussion
• Al Morton There are many ways to end up with a RI as defined by the RA and validated as correct by RC