• Release Management
  • Lifecycle Management


("AI" = Action Item)

  • Release Management Gap Analysis - Deliverable
    • Cadence – how often
    • Release Dates – actuals / when
    • Core – OPNFV, OVP
    • Secondary – CNCF, Kubernetes, OpenStack
    • Dependencies w/upstream and downstream
    • Cascading visual
    • CNTT components RM & RA vs. RI & RC
    • AI – Jonathan Beltran  strawman approach to gap analysis
  • Problem Statement – how can our release cycle in any way enable the community to accelerate VNF onboarding?
    • AI - Toshiyasu Wakayama With respect to release lifecycles, what problems might operators be trying to solve/understand from a planning perspective with respect to VNF certification?
  • Lifecycle Management
    • leverage for feedback from GSMA on viability of VNF certifications
    • Reference Model needs to be made a GSMA specification (long-term)
      • AI – Toshiyasu Wakayama reach out to Jisu Parkfor ideation of approach to making Reference Model a GSMA specification long-term
        • E.g. what approach should CNTT take in early discussion, ideation, and options

  • No labels


  1. Hey Jonathan Beltran - I'm concerned that defining a release and lifecycle management for RI/RC, you would essentially be recreating what OPNFV has and does for one release cycle. Maybe your plan is to articulate the CNTT asks and bring them to OPNFV for discussion/adoption? Maybe I'm mistaken of your intent?

  2. Jim Baker Certainly not looking to recreate any wheels. That's why the first question is 'what is our mandate'? It should probably focus on the Lifecycle and feedback loop side. I'm just not clear what part of 'release' CNTT needs to be concerned about given that the RI and RC now enable a gating effect in the VNF product go-to market plans vs. opt in / opt out validation. And correct, at a base level there should be an alignment around assumptions and needs.