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 2 Next »

Working Draft

Charter

The 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 verification through publicly available CNF compliance test tooling based on requirements and tool-sets developed within OPNFV, ONAP and CNCF communities.


Source:  LF Networking


Compliance & Verification Program

OVP2.0 E2E Compliance and Verification Program adds additional collaboration with the CNCF in the testing and verification of Cloud Native Network Functions.

Source: LF Networking


Verification and Certification Process

OPV 2.0 will provide an open source test suite which enables both open and closed source CNFs to demonstrate conformance and implementation of cloud-native practices. Compliance to the verification process will result in a LFN Cloud Native CNF badge(s). The LFN CNF badges should provide value for both operators and commercial vendors.

Cloud Native Network Function (CNF) Best Practices Criteria

(Propose that the below should be aligned, agreed, and later decomposed into testable items.  We should sort with mandatory first and optional (but still verifiable) criteria at the end.


CNF Best Practice Criteria

1

CNFs are decomposed into loosely coupled collection of services (e.g. use micro-services design).

2

Micro-services should, where possible, be independent of the host operating system.

3

Micro-services should utilize well defined declarative APIs

4

Micro-services should be designed with a clean separation between stateful and stateless services (have separation of state storage and business logic)

5

Clear separation should exist between micro-services (e.g. use of containers)

6

Micro-services should provide a mechanism to verify container content. Containers should not require root level permissions. It should be possible to secure API access to a micro-service using common methods.

7

Micro-services should be resilient (self-healing and distributed)

  • A strategy for self-healing accompanies the micro-service
  • Is compatible with declarative configuration and container orchestration

8

Micro-services should be elastic (vertical and horizontal scaling in response to load)

  • A strategy for auto-scaling accompanies the micro-service
  • Is compatible with a declarative configuration and container orchestration

9

Micro-services should be dynamic - where possible, have a small footprint and fast startup time enabling efficient use of resources and rapid scaling.

10

Micro-services may utilize a service mesh for service-to-service communication over a network

11

Micro-service/Container life-cycle is managed by an orchestrator (e.g. K8s)

12

Micro-services utilize immutable infrastructure:

A

  • Infra is easily produced and repeatable (automated)

B

  • Infra is consistent (infrastructure elements are identical each time they are implemented)

C

  • Infra is disposable (create, destroy, replace, resize, etc.)

D

  • Configuration of infra is protected from changes after deployment

E

  • Deployment process of infra is versioned, automated, and all dependencies packaged together with the application during build phase and then used in deployment

F

  • Observable (infrastructure elements externalize their internal states to allow metrics, tracing, and logging)
  • No labels