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

Compare with Current View Page History

« Previous Version 5 Next »

This page tracks the related materials/discussions/etc related to ONAP container/Container Orchestration Engine(COE) effort.

As starting point, this effort has started as small subgroup of multicloud as task force.As the efforts evolve, logistics would be revised. Maybe this task force would be promoted to a independent group or an independent project.


Meetings

doodle poll


Meeting Minutes



Project template for project proposal

Project Name:

Project name: ONAP container support: OCS
container support:Repository name: OCS


Project Description:

The effort will investigate/drive a way to allow ONAP to deploy/manage Network Services/VNFs over container/COE.

Increasing VNF density on each node and latency requirements are driving container based VNFs.  This project enhances ONAP to support VNFs as containers in addition to VNFs as VMs.

  • Support for multiple container orchestration technologies as VIM(Virtualized Infrastructure Manager) technologies - Support container orchestration technology as VIM by ONAP and allow VNFs to run within container technology and also allow closed feedback loop same to VM based VIM. e.g. openstack
  • Support for co-existence of VNF VMs and VNF containers - Add container orchestration technology in addition to the traditional VM-based VIM or environment managed by ONAP. So that VNFs can be deployed within container by ONAP.
  • Support in various ONAP projects to bring up VNFs as containers by standardized definition of workload as VM or container (e.g TOSCA model)
  • Enhance VNF SDK to support container based VNFs.
  • Support for uniform network connectivity among VMs and containers.

Goal and scope

Some of architecture/design are under discussion. subject to change depending on the outcome of discussion

  • Have ONAP take advantage of container/COE technology for cloud native era
  • Utilizing of industry momentum/direction for container/COE
  • Influence/feedback the related technologies(e.g. TOSCA, container/COE)
  • Teach ONAP container/COE instead of openstack so that VNFs can be deployed/run over container/COE in cloud native way


Functionality


  • Allow VNFs within container through container orchestration managed by ONAP same to VM based VIM.
  • Allow closed loop feedback and policy
  • Allow container based VNFs to be designed
  • Allow container based VNFs be configured and monitored.
  • Kubernetes VIM as initial container orchestration technology under Multi-Cloud project.

API/Interfaces


Multi cloud project


  • Registry logic to reigster container instances. E.g. k8s instances and its API endpoint with its features.

  • At first new TOSCA node definition will be introduced to express container requirement. In long term, contributing to TOSCA specification would be in scope side project.

  • API enhancements   in Multi-Cloud project to enable container orchestration technologies through planned model driver API.(currently TOSCA): First target is Kubenetes plugin - converting the input from northbound API to kubernetes API.

  • Southbound plugin in Multi-cloud project to talk to container/COE. The first target will be kubernetes API.

  • Plugins to FCAPS/data management to report statistics(e.g. Cpu usage, memory usage) from underlying containers to upper ONAP component

  • API enhancements (if needed) in Multi-Cloud project to realize uniform network across VMs and containers instantiated by VIMs TBD : container orchestration api or CNCF using flannel with Multus


SO and Controllers(SDN-C, APP-C, VF-C etc...)


  • Enhancements in SO and controllers to take advantage of enhanced Multi-Cloud model driven API that may be enhanced for container orchestrators. This will be done as a part of multi-cloud project.

  • This implies sort of converters from VNF models(VNF descriptors, more higher level, it can be TOSCA ) to  enhanced Multi-Cloud API


AAI


  • If necessary, enhance AAI schema to describe feature/capability of managed environment. This can be generic among VM-based VIM and container-based VIM.

  • multi-VIM project to report container orchestration features/capacity to AAI


DCAE


  • Plugin for event/stats collectors for containers


Policy


  • Awareness of container requirements. It won’t’ be directly referenced as container technology, but as, for example, performance requirement/low overhead requirement etc such as they can be achieved by container technology.


VNF SDK



  • Allow container image with TOSCA



  • First target for first release

    • Container orchestration technology: First target of container orchestration is kubernetes. But support for other container orchestrations can/will be addressed later.

    • Sample VNF running within container: sample VNFs as vFW/vDNS

    • test


  • Target for later release

    • Installer/test/integration

    • VNF SDK

    • Policy

    • Feedback to modeling project

    • More container orchestration technology

    • More than sample VNFs

Non-Goal/out of scope

Architecture Alignment.

  • How does this project fit into the rest of the ONAP Architecture?

    • The architecture (will be)is designed to enhancement to some existing project.

    • It doesn’t introduce new dependency

  • How does this align with external standards/specifications?

    • Convert TOSCA model to each container northbound APIs in some ONAP component. To be discussed.

  • Are there dependencies with other open source projects?

    • Kubernetes pod API or other container northbound AP

    • CNCF(Cloud Native Computing Foundation), OCI(Open Container Initiative), CNI(Container Networking interface)


This slide is cited from multi-cloud slide and modified for this proposal. The first target will be small part of them.

  • Multicloud driver to register k8s instances
  • Multicloud southbound driver to talk to k8s api server
  • SO adaptor to talk to multicloud: this will be addressed by multicloud project. Not specific to this proposal
  • Enhancement to policy to schedule NS/VNF to container with understanding of tosca node definitions that require container.
  • Enhancement to TOSCA(new node type definition) to allow containerized VNFs


Resources:

  • Primary Contact Person

  • Names, gerrit IDs, and company affiliations of the committers

    • TBD

  • Names and affiliations of any other contributors

    • TBD

  • Project Roles (include RACI chart, if applicable)

    • TBD

Other Information:

  • link to seed code (if applicable) N/A

  • Vendor Neutral

    • if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?

  • Meets Board policy (including IPR)

Use the above information to create a key project facts section on your project page


Key Project Facts

Project Name:

  • JIRA project name: OCS (TBD)

  • JIRA project prefix: ocs (TBD)

Repo name: ocs (TBD)

Lifecycle State: TBD

Primary Contact: isaku yamahata, Intel

Project Lead: Isaku Yamahata, Intel

mailing list tag [Should match Jira Project Prefix] OCS(TBD)

Committers:

TBD

*Link to TSC approval:

Link to approval of additional submitters:



  • No labels