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

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

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 labels