Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Cloud Native Computing Foundation (CNCF)

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

...

  • A. Cloud Platform Conformance
    • A1. Performance:
    • A2. Functional:
    • A3. Cloud Native:Functional (i.e. CNTT RA-2 Compliance)
  • B.   CNF On-boardingConformance
    • B1. CNF CompliancePackaging: (Helm v3.0, TOSCA, HEATCloud Native (i.e. CNF Conformance)
    • B2. CNF LCM: CNF Metadata for on-boarding and LCM
    C. CNF Conformance
  • C1. Performance:
  • C2. Functional:
  • C3. Cloud Native
    • . Functional (i.e. CNTT RA-2 Compatibility)
    • B3. ONAP
    • B4. Performance
  • C. Cloud Platform Benchmarking

MVP proposal

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

    • A1: Cloud Platform Conformance (may be partial)
    • B1 & B2: CNF Compliance

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

Workstreams Proposal (see OVP 2.0 Workstreams)

MVP Roadmap - NEEDS COMMUNITY REVIEW/UPDATE

...