OVP Phase 2 Project Mapping and Relationships

Status: DRAFT

Overview

This is an attempt to map the ecosystem Open Source projects in the OVP Phase 2 umbrella and their relationships.  The goal is to link the source of “what to validate” (i.e. requirements) to either testing specifications (i.e. Certifications) or testing implementations.  A project being in a box only implies it is potentially aligned to provide the functionality – not that it already has it or we confirmed alignment.

Mapping

Open Questions/Issues

• RC-2 does not plan to handle certification of the CNFs, but rather the NFVIs.  However, the diagram on the OVP 2.0 Boot Strap page implies that RC-2 does play a role.  We either need to change the scope of RC-2 or correct the diagram.  
• CNF Conformance currently has tests for CNFs and the Kubernetes platform itself (ex: CNI tests, K8S API tests). CNF Providers and NFVI providers are different use cases. Should we split these tests?
• No project in the LFN umbrella is currently defining requirements for what a CNF needs to comply with. The only project identified is the CNF Conformance project which is part of CNCF TUG. Given that a CNF will need to be compatible with a given CNTT RA and RI, it would seem there needs to be a project somewhere in CNTT to manage those requirements and potentially tests.  If there are more general "Cloud Native" requirements that aren't specific to the CNTT, then we could create a requireement to comply with those external requirements and test suites.
• There was mention of using ONAP as a vehicle to define CNF onboarding requirements, but this presents some challenges:
  • ONAP’s support of CNFs is fledgling and still under development. As such, no requirements currently exist for CNFs in ONAP and they are likely go under significant change as support is built out.
  • Additionally, ONAP is not required for a CNF to utilize an RA-2 based implementation.
  • Suggestion: We need a place within CNTT to define the requirements of a CNF to be compatible with RA-2. ONAP may define additional requirements to onboard a CNF into ONAP for orchestration and management, but that would be a separate and optional set of requirements that would only be applicable when using ONAP.  This may impact how the badges are defined as well.
• Testing Category Feedback
  • The 2 categories of CNF Conformance and CNF Onboarding seem to significantly overlap. Onboarding artifacts would seem to be just another aspect of CNF Conformance rather than a category itself. 
  • In Cloud Platform Compliance, the distinction between the categories Cloud Native and Functional are not clear to me. Is a distinction necessary? RA-2 already has requirements such as the implementation must be compatible with K8S software conformance tests. If we are going to have sub categories of compliance, then I suggest we better align them with RA-2 categories (ex: Capabilities, Architecture, etc.)
  • Under CNF Conformance, it's unclear what Functional means.  Does it mean the CNF performs the function it is designed to do (e.g. firewall) or does it mean it is compatible with specific lifecycle functions common to all CNFs
  • Suggested Categorization:
    • Cloud Platform Compliance
      • Performance/Non-Functional - Does the NFVI meet specific performance benchmarks, and handle specific non-functional requirements
      • RA-2 Capabilities Alignment - Does the NFVI include all mandatory capabilities defined in RA-2
      • RA-2 Architecture Alignment - Does the NFVI meet the mandatory architecture requirements defined in RA-2
    • CNF Conformance
      • Artifact Compliance (images, descriptors, charts, etc.) - Do the charts, configurations, descriptors, images, etc. meet CNF requirements
      • Functional - need a better definition of the scope of this
      • Performance - not sure what would be validated here.  It wouldn't seem to be a matter of conformance.   Maybe CNF Benchmarking is something that should be in it's own category.