...
| Gliffy | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The remaining ONAP components/projects are now ONAP Core components:
...
The management system is overwhelmed by the frequency and quantity of alarms, KPI, trace information with the growth of new service and service complexity.
Several incident reports/alarms could be collected and aggregated into a single incident
Repository-Based ONAP Integration (Future topic)
The following diagram depicts a possible CD/CD Repository-based Network Automation Choreography use cases.
ONAP CI/CD and Repository mechanisms can be substituted by vendor/operator mechanisms.
Repository holds artifacts, intents and other models.
ONAP components and vendor / operator components send their intents to the Repository.
OSS Client sends their intents to the Repository thru Intent Manager, or UUI or else.
User-level Intents will be translated in UUI.
System-level Intents will be handled by Intent Manager.
CD monitors the Repository and reconciles for events
Thru CD, the corresponding intents will be delivered to the ONAP components thru the operators.
The operators will work as façade to trigger ONAP component functions (it would be an optional path, based on use cases).
ONAP components do their business decisions and handles actuations.
The actuations can result in actions and/or another-level of intents, which will be stored back to the Repository for next events.
Images and/or Helm Charts and others will be stored thru the CI pipelines, which to be used by ONAP components, as needed.
ONAP components can leverage the existing ONAP interfaces, based on their needs – a hybrid mode between declarative and imperative APIs will be supported.
ONAP ends up having smaller imperative actions that can be triggered by different events.