Anuket Project

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

Compare with Current View Page History

« Previous Version 5 Next »

Objectives:

OPNFV started the open source NFV journey largely based on a VM approach, specifically Openstack. This approach means more than just VM as basis of virtual compute unit, but also the implies a "virtual appliance" model. This model influences the overall architecture, software and service design philosophy in many aspects beyond the choice of hypervisors. Supporting cloud native for NFV, therefore, means supporting ALL of the following three aspects (as defined by CNCF and others):

1) Supporting containers,

2) Supporting management and automation of containerized software

3) Supporting micro-service model of software

More background information can be found in this ONS Technical Forum Presentation. (March 2018, Los Angeles, CA)

These three aspects are inter-linked closely in order to fully realize the benefits of cloud native paradigm for NFV. Therefore, our overarching objective is to integrate a best of breed cloud native software stack and best practices for supporting cloud native deployment of NFV solutions for all end users and high priority use cases. Specifically,

  1. Container and container management
      - Various types of container implementations
      - Performance, security, other aspects of container improvement
      - Orchestration : Kubernetes (auto deployment, scaling, management etc.), Kubernetes + Openstack (including Kubernetes on Openstack, and other variations)
      - Integration of these upstream components
      - Goal is to move the integration process to XCI style continuous integration with both Openstack and Kubernetes

  2. Container networking
      - There are many aspects of container networking, some involve VNF data path but many don't.
      - For VNF data path, i.e. hard core packet processing, an accelerated implementation may be desirable. OPNFV should work with upstream projects (and cross project within LFN) to integrate best solutions. We will strive to see this be fully aligned with upstream CNCF/Kubernetes solution.
      - For other cases, OPNFV should be fully staying with upstream CNCF/Kubernetes solution.
      - Choose preferred methods based on user/use case requirements. The goal should be small number of operationally ready solutions with pre-excluding new innovations in this area.

  3. Micro-services support
      - Micro-service service mesh
      - Micro-service visibility/data collection and analysis, and related tools and automation methods
      - Tools for best practice of micro-services
      - Software (micro-services) components commonly needed for NFV use cases
      - Test methodologies and tools in the micro-service/cloud native approach

  4. Continuous deployment/delivery (CD)
      - One of the integral part of being cloud native software is its continuous deployment
      - We should extend current CI (strictly speaking XCI is still CI, just for clarification of terminology) to new CD for cloud native software. See this proposal from the ONS Technical Forum: Extending CI/CD to support Cloud Native VNFs and Operations.
      - Note that this toolchain works for both containers and VMs - one can adopt this style of CD for VM as well - however, the initial objective should be focused on container first.
      - Will require "long lasting computing resources" - this can be current UNH pods being allocated for this purpose, Pharos-pods dedicated for this purpose, virtual public cloud (GCE, AWS, ...) paid for for this purpose, or new resources.
      - Software tools and automated tests that implement this CD pipeline. 

  5. Concrete use cases and sample applications
      - Use case driven (user/customer driven) is an important way to make OPNFV more relevant to customer needs and be more "consumable".
      - Work cross project to identify common priority use cases. Future deployment should be a focus for us as today's commercial deployment has yet to adopt cloud native in large scale.
      - One of the outcome of these sample VNFs should be a best practice document helping the community/vendors/customers understand the challenges involved and best methodology of moving to cloud native.

  6. Cross project collaborations
      - ONAP also aims to move to cloud native. We need to position OPNFV in helping ONAP achieve their goals without unnecessary replication.
      - FD.IO has goals in high performance data path for cloud native VNFs. We should investigate best way to integrate that as one of the acceleration methods.
      - The CD (continuous deployment) initiative is applicable for all projects within LFN, and related to upstream (CNCF, Openstack), and of course the XCI initiative, Lab-as-a-service/Pharos etc.
      - Cloud native is a general theme that we should push together in LFN.

Related projects in OPNFV:

Projects in OPNFV are currently working towards at least part of the above objectives:

Proposed next steps:

1) Coordinate CI/CD and deliverables for best user experience

2) Coodinate documentation to cross reference and present a consistent reader/user experience


3) Jointly develop test framework and tools


4) Work with edge initatives to support edge use cases


5) Cross LFN-project collaboration with : (a) ONAP


Raw discussions during zoom meetings:

Open items discussed at meeting on April 17, 2018:

  • storage solutions supporting containers/cloud native
    • container friendly storage abstraction
      • rook/cncf
    • how to implement stateful vnfs using these storage types
      • should we include "databases" as well
  • hybrid environments: 
    • container4nfv: k8s, k8s on openstack, openstack on k8s, or side-by-side
    • other light weight compute units: e.g. kota, virtlet, unikernels
    • different container runtimes
  • ingress/egress networking solutions
  • bump-in-wire networking functions in cloud native environment
    • e.g. legato.io/fd.io
    • e.g. kernel - BPF based
    • other approaches?
    • how does it integrate with the rest of cloud native micro-services
    • in relation to CNI/container networking
  • Other communities or standards cooperation
  • No labels