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

Version 1 Next »

Background

ONAP is set of projects. It is unlikely that ONAP will be deployed in its entirety by customers.  It is envisaged that there could be multiple profiles, with each profile satisfying a set of deployments.  A given ONAP profile may not require all projects and also it may not require all Microservices in the chosen projects. 

In this document, we are defining one profile - ONAP4K8S.

Why ONAP4K8S?

Akraino ICN BP family (https://wiki.akraino.org/pages/viewpage.action?pageId=11995140) has chosen ONAP for orchestrating workloads across multiple edge locations.  ICN BP addresses the edge locations with K8S resource orchestrator, that is ICN BP is not used in cases where Openstack or non-K8S based resource orchestrators are used.  Keeping this in mind, ICN is requesting bare-minimum ONAP that is required to deploy workloads in K8S regions.

Many Enterprises are adopting K8S to deploy workloads in their local data centers/edge locations.  Many feel that ONAP asis can be a challenging to install and maintain.  Also concerned about security challenges associated with the code that is unused.  Second challenge is the amount of memory and CPU power it requires to run the entire ONAP.   Since, many components of ONAP are not required, it is felt that a profile of ONAP would be good.  Hence ONAP4K8S.

ONAP4K8S requirements 

Based on ICN requirements and talking to few Enterprise customers, following are the requirements for ONAP4K8S

  • ONAP4K8S to contain Microservies that are required for K8S based workload deployments.  
  • ONAP4K8S shall not have Microservices that are not used.
  • ONAP4K8S shall provide a way to onboard resource bundles, applications consisting of multiple resource bundles.
  • ONAP4K8S shall use cloud native open source projects for infrastructure
    • fluentD for logging.
    • Jaguer for tracing
    • ISTIO/Envoy for service mesh 
  • ONAP4K8S shall maintain security of passwords and private keys.
  • ONAP4K8S shall provide 'Role Based Access Control' for all operations.
  • ONAP4K8S shall scale-out.
  • ONAP4K8S shall use distributed databases 
  • ONAP4K8S should have simple UI to onboard, instantiate, terminate and provide Day2 configuration

ONAP4K8S package

Keeping above requirements in mind, current thinking is to create ONAP4K8S package with following containers

From ONAP:

From CNCF and other open source projects:

Deliverables:

  • Create ONAP4K8S helm chart (Figure out how OOM can be used to do this. If not, may need to go with its own set of helm charts)
  • Ensure that ONAP4K8S package can be used to instantiate vFW and EdgeX applications.




  • No labels