Page Comparison

...

• Jim Baker Heather Kirksey  Scot Steele  Beth Cohen Al Morton David McBride Qiao Fu  Toshi Wakayama Ulrich Kleber

...

•  Georg Kunz Trevor Cooper William DIEGO (Orange) Jonne Soininen Lincoln Lavoie Ildiko  Sunku Ranganath (Deactivated) Phil Robb Tom Van Pelt (Deactivated)

Discussion items

Action 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