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)