Skip to end of banner
Go to start of banner

OVP 2.0 Boot Strap

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

All members are encouraged to contribute directly into this working draft.  See also the OVP 2.0 Technical Ideas page

Charter

The LFN OPNFV Verification Program Phase 2 (OVP 2.0) is an open source, community-led compliance and verification program to promote, enable, and evolve a thriving ecosystem of cloud-native telecoms where Cloud Native Network Functions (CNFs) from different vendors can inter-operate and run on the same immutable infrastructure.  It includes CNF compliance and verification testing based on requirements and best practices put forth by both the CNCF and CNTT.  These requirements feed tool-sets and testing scripts developed within OPNFV, ONAP and CNCF communities.

Vision

An end to end set of compliance/conformance tests and testing toolchain for independently verified Cloud Native Functions for use in Telco environments.

Who are participating?

Linux Foundation Networking

  • Open NFVI project (OPNFV)
  • Open Networking Automation Project (ONAP)
  • Compliance and Verification Committee (CVC)

Common NFVI Telco Taskforce (CNTT)

  • Reference Architecture 2 workstream (RA2)
  • Reference Implementation 2 workstream (RI2)

Cloud Native Computing Foundation (CNCF)

  • Telecom User Group (TUG)

5G Cloud Native Network Demo (Brandon Wick)


How to engage

  1. Join the mailing list:  https://lists.opnfv.org/g/OVP-p2
  2. Subscribe to the calendar for the meetings: https://lists.opnfv.org/g/OVP-p2/ics/7337234/1823902251/feed.ics
  3. Engage in the discussions at the weekly meetings
  4. Share your ideas on these wiki pages and comment sections at the bottom of every page


What is the Minimum Viable Program

The end state vision is spelled out above and since it is likely a multi-year endeavor, what can we do this year to chart the direction and set in motion the program that achieves the vision?

First, the envisioned process is diagrammed below:

E2E CNF Conformance Cycle 

In the below diagram the “?” indicate processes that need definition and refinement for the differing execution environment of OVP Phase 2.


Categories of Conformance:

  • A. Cloud Platform Conformance
    • A1. Performance/Non-functional (security/resource utilization/etc):
    • A2. Functional:
    • A3. Cloud Native:
  • B.  CNF On-boarding
    • B1. CNF Compliance: Packaging: (Helm v3.0, TOSCA, HEAT)
    • B2. CNF LCM: CNF Metadata for on-boarding and LCM
  • C. CNF Conformance
    • C1. Performance:
    • C2. Functional:
    • C3. Cloud Native: 

What needs to happen/Decided on:

  • Decide on Tooling:
    • Cloud installation tools into a given lab.
    • Basic Testing Tools.
    • what open source project is responsible of this.
  • Decide on Lab:
    • Community development resource access
    • Platform details - specific HW details, login info,etc.
    • what open source project is responsible of this.
  • Decide on Badging Process:
    • Test results review process
    • Portal and badging process
  • Decide on OpenSource Testing Projects
    • What project will deliver what test category (A, B, and C)
      • A: ?
      • B: ?
      • C: ?

MVP proposal

Not every thing can be tackled in the MVP, here are two elements that can be tackled for MVP.  

    • C3: CNF Cloud Native Conformance (Per CNCF CNF Conformance Characteristics): 

• Compatibility - CNFs should work with any Certified Kubernetes product and any CNI-compatible network that meet their functionality requirements.
• Statelessness - The CNF's state should be stored in a custom resource definition or a separate database rather than requiring local storage. The CNF should also be resilient to node failure.
• Security - CNF containers should be isolated from one another and the host.
• Scalability - CNFs should support horizontal scaling (across multiple machines) and vertical scaling (between sizes of machines).
• Configuration and Lifecycle - The CNF's configuration and lifecycle should be managed in a declarative manner, using ConfigMaps, Operators, or other declarative interfaces.
• Observability - CNFs should externalize their internal states in a way that supports metrics, tracing, and logging.
• Installable and Upgradeable - CNFs should use standard, in-band deployment tools.
• Hardware Resources and Scheduling - The CNF container should access all hardware and schedule to specific worker nodes by using a device plugin.

(Should note that these are currently not characteristics that will be sufficient and/or accurate for Telecom use.  As an example, in 5G the CHF (Charging Function) will be required to provide stateful transaction processing for services that are monetized on a metered basis – e.g. charging per minute for a live video chat session to a healthcare professional.  It is unclear if these types of distinctions will be specified as work coming from CNTT.).

    • B1: CNF Compliance.

Workstreams Proposal (see OVP 2.0 Workstreams)

MVP Roadmap - NEEDS COMMUNITY REVIEW/UPDATE

  • Define MVP - by April 1
  • Validate approach with partners (CNTT, CNCF, LFN projects) - during weekly OVP p2 meetings <ADD LINK>
  • Implement “HelloWorld” sampleCNF test - Hackfest at June Developer and Testing Forum
  • Implement MVP - by Q1/Q2 2021

Immediate tasks and AIs:

  1. Identify cloud infrastructure installation tools.
  2. Identify Labs for testing and human resources who will manage the labs (in addition to the testers)
  3. Identify projects to develop test scripts and tools to perform Cloud infrastructure functional testing and agree on scope.
  4. Agree on scope of CNF Onboarding testing.
  5. Identify projects to develop test scripts and tools to perform CNF testing and agree on scope.
  6. Agree on CVC portal.

OLD: Workstreams Proposal


Development/Lab environment [Primary Owner OPNFV+CNTT] - What are the lab resources for hosting configurations for developing the NVFI and running on-going CI/CD verification tests? How can a “Lab as a Service” (LaaS) be instantiated for CNF/NFVI testing, development, and validation efforts? Does the CNCF TestBed meet the needs?

Test Tooling/Test Suite Development Based on Above Categories [Primary Owner:  OPNFV]: Understand dependencies and what can be parallel processed. Also, what is the overall program test framework (e.g., Dovetail or something similar) that can plug in tests from projects and communities….

  • On-boarding/Lifecycle Management testing - What are the preferred tools/methodologies for repeatably creating an NFVI environment supporting containers? Can CNFs be deployed and respond to basic lifecycle events? 
  • Platform test - What is the source for the tests and toolchains for developing and verifying the NFVI platform for container based CNFs? Are there existing CNCF infrastructure tests/standards that should be co-opted? What level of micro-services should be integrated into the standard platform? How do we validate each of the micro-services against a specific version of the platform?
  • CNF test - What is the source for the tests and toolchains for developing and verifying the CNFs as the SUT atop a verified NFVI? How does the CNCF test bed integrate into the OVPp2 workflow and test process? With many micro-services as “helper functions”, how do we validate each of the micro-services against a specific version of the CNF?
  • Performance testing - Both the infrastructure and CNF performance characterization would be useful - this is very difficult to cooperatively define/execute (DEFER)

CVC portal [Primary Owner: CVC] - Define the UI for consumers of the CVC and on-ramp for producers of NFVIs and CNFs to publish their successful validation process results? How to the CNF compliance tests (CNCF) figure into the telco focused OVPp2 process? 

Governance/Structure/Mktg Framework [Primary Owner: CVC] - Includes 3rd party labs, white papers, slide decks. With input from MAC


  • No labels