Brief Project Overview (brief as it should be known)

CNFO - Containerized Network Function is orchestrating the network functions deployed in a containers

This functional feature in ONAP would be leveraging the existing functionality of K8s based orchestration to the next level and would be making the helm charts the first class citizen.

The current efforts focus on leveraging the design and runtime functions of ONAP to support the CNFs through helm charts.


New component capabilities for Guilin, i.e. the functional enhancements, if applicable

SDC:
On-board the helm and process it as an artifacts of the CSAR to be distributed
On-board Helm Charts
Resource model to include type
(Design CNFs over helm)
Distribute them

SO:
Wont consume the Helm by itself but parse it and push it forward to other ONAP components
Parse the CSAR, extract helm
SOL003 adapter enhancements
New K8s Adapter (Interface to K8s Proxy)
(Model driven workflow)

K8s plugin :
Separation from MultiCloud
Perhaps call it as K8s Proxy
Support new API for the SO interaction

AAI:
Persist the Service instance
(Persist CNF as a resource)

ETSI Catalog DB:
Persist the ETSi VNFM data (IFA-29 and IFA-40 )
Persist Images

K8s Adapter :

A new adapter (pod) inside SO

This would be used to interact with the K8s plugin

New or modified interfaces

New Interfaces around SO - K8s Plugin

Enhanced functions of the SDC, SO,  and AAI around the helm chart and CNF resouces

If they are modified, are they backwards compatible?

Yes, the existing functionalities around the K8s would still be functional.

Interface naming (point to an example)

Consumed API from other projects

Project

API Dependency

Notes



































Published API

Project

API

Notes














Reference to the interfaces.

(Reference to the the swagger.json file(s) whenever possible)

What are the system limits?

.

Involved use cases, architectural capabilities or functional requirements.


Listing of new or impacted models used by the project (for information only).

  • Identify any High Level Information Model Requirements.   See: ONAP R7 Modeling High Level Requirements
    • Models based on information exchanges from Use Cases
    • Models documenting existing implementations
    • Forward looking models that may be implemented in future releases
  • Describe how exposed APIs are mapped to information models

(list all the relevant Jira tickets)


Any other details that are specific to this functional enhancement or UseCase.






  • No labels