Page tree
Skip to end of metadata
Go to start of metadata

Below listed the working progress, discussion and comments within the sub-committee members. Please provide your feedback, comments and suggestions in this page. The following working items will be discussed sequentially.


No. 1: Define the mission/strategy/vision for OPNFV 2.0–Deadline Mar. 3

No. 1: Define the mission/strategy/vision for OPNFV 2.0–Deadline Mar. 3


NO. 2: Working Items for the Sub-committee (Rank by priority order):  – Deadline:  Mar. 17

Working Items for the Sub-committee (Rank by priority order)


NO. 3:  Define the specific metrics that would measure OPNFV be ready to catch the ball from CNTT

1.Healthy community

  • making sure OPNFV is healthy enough to address the implementation and comformance challenges CNTT refer to.
  • several metrics can be defined to measure the health of OPNFV:
    • diversity of sample implementation: do we have enough active projects on implementation? The implementation should probably cover most of the popular implementation upstream tools, and have enough impact on the upstream as well. This will make sure the RA in CNTT can be properly addressed in OPNFV with multiple active implementation projects, with enough hands and experience to accomplish RI based on the most popular tools, and enough influence to make sure whatever detected are not following RA accordingly can be modified in upstream timingly.
    • do we have enough active projects on testing? With these, we can make sure to provide test capability to whatever CNTT expect OPNFV to provide for comformance purpose. We should make sure the test framework for OPNFV can cover almost every component in a typical RI, including hardware, platform, services(if necessary, not sure of this)
    • tangible results in realizing goals of CNTT 
    • can we provide a matured CICD pipeline for continuous implementation and testing, which CNTT comformance labs, operators can utilized as well. This will require our CICD pipeline can also work with multiple vendor products as well, not only just for OPNFV scenarios and testing. 

2. release management:

  • the current release cycle of OPNFV and CNTT are not the same. CNTT mainly releases documents, however the detailed RI and RC are rely on OPNFV. So when CNTT put out a new release, it will be confused on which release of OPNFV it is based on?
  • The release management is not synchronized. Therefore we can't make sure those which are important for the next release of CNTT are properly addressed in OPNFV. Specific cycle should be defined to capture the requreiment of CNTT in time
  • start by define what release consist of. sequencial things to release. 
  • the two communities should have combined release management

action point: Scott will help put this up on Thu. CNTT Gov call, and will have specific discussion on this on next week's CNTT Gov streering meeting.

3. Issue tracking (this probably is not a requirement just to OPNFV, but need collaboration between OPNFV and CNTT. However, I think we need to put it here so it could be something TSC and community should think of better schema to solve this)

  • when we detect issues in CNTT, a new Jira should also be created in OPNFV. it is difficult to track both issues. 
  • issues that are crucial in CNTT are not properly revealed in OPNFV, difficult to track importance 
  • should be solved through technical method rather than using man-power to track

Action point: Fu Qiao and Scott will bring this to OPNFV TSC and CNTT Gov, and will have a combined call for CNTT and OPNFV in Apr. Virtual call.

4. fine translation from RM/RA→RI/RC (this probably is not a requirement just to OPNFV, but need collaboration between OPNFV and CNTT. However, I think we need to put it here so it could be something TSC and community should think of better schema to solve this)

  • there has been debates about how to track RI/RC to make sure it maps with RM/RA, currently man-power is used to making sure the right things happen
  • technical method should be defined and promote for this. For example, requirement in RM/RA can be listed as bullet in doc/jason/yaml, easy for tools to read, then specific issue can be created automaticlly, then when implementation/test case cover the requirement, the bullet can be marked as solved automaticlly. Of cause, this first requires CNTT doc writer to have capability to translate their wording requirement into bullets with specific testing items exatly. 

NO. 4:  Gaps for OPNFV to catch the ball from CNTT, things OPNFV and CNTT should do

This is a list of items and gaps detected when discussing about item NO. 3, which require attention and next steps from OPNFV and CNTT. The OPNFV 2.0 team is currently trying to bring attention to both TSCs

  1. What to release? Should have well defined deliverables.
    1. OPNFV releases tools and tests to automaticly verify infrastructure, not releases an infrastructure
    2. OPNFV release testcases that will make sure VNF/CNF interoperability with conformant infrastructures
  2. Release management
    1. release sequence: Define the release sequence of CNTT and OPNFV, and the correlation of the releases.
      1. current progress:
        1. CNTT has two release from now, Q2 and Q4 each year. A new release cycle is under discussion within CNTT. Should bring OPNFV into this discussion and put OPNFV into the over all release map to upderstand the sequence and correlation
    2. release management:  general release management for OPNFV and CNTT to make sure OPNFV release will follow the sequence of CNTT and address key bullet of requirements
  3. Project allocation
    1. implementation projects: does CNTT require only one installer for RI, or CNTT is eager for multiple implementation projects in OPNFV? What benefit will bring for multiple implementation projects
    2. testing projects: assessment of CNTT requirement to OPNFV test capabilities is happen here https://wiki.opnfv.org/pages/viewpage.action?pageId=52789998. Would expect this would provide us with detailed concept of which test project is urgent to bring back/recreate/create
    3. infra: provide Infra recomendation and requirement and technical capability for conformance testing and field trails, including lab setup, CI/CD toolchain
  4. Issue tracking
    1. generate automatic/technical/standard way to track issues detected in CNTT to OPNFV, and vice versa
    2. currently all issue tracking is using man power and personally connection
  5. Documentation transfer plan
    1. which part will be transfered?
    2. when to transfer?
    3. how to transfer? do we have technical issues for this?
  6. Translation from RM->RA->RC->RI→OPNFV , automatic/technical/standard process to make sure this chain can work and nothing is lost
    1. gap detect currently: requirement in RA is rather high level and would be better to tranlate to detailed test spec and test items before RC and OPNFV test projects to review the requirement and generate test cases

NO. 5: What should we do to get the ball rolling?

  1. set up the cycle path for CNTT reqruiement→CNTT test case→OPNFV test tools→OPNFV release→RC/OVP test. Making sure every entity agree and understand its duty and finish the gap.
    1. for the upcomming field trail, use the least number of test cases that exist now, but make sure to cover the whole path in the right way.
    2. try to extend more test cases and test tools according to the path
    3. this requires a collaboration with both TSCs for OPNFV and CNTT



  • No labels