( by Vijay Venkatesh Kumar, Wen Shang, Ashoke Sharma, Shrikant Acharya, Diana Zhang)
<<place holder for documenting the design to facilitate the OTI feature addition in DCAE>>
...
Summary
Network Topology can evolve over time, so there is a need for platforms to be able to receive these updates and take appropriate actions. From a DCAE standpoint, as new xNF gets instantiated, DCAE MS may need to be reconfigured to poll data from new sources. A new DCAE platform components – ONAP Topology Interface (OTI) will listen on external topology updates and determine MS to be reconfigured/instantiated and trigger updates via other DCAE platform components.
| Table of Contents |
|---|
High Level Architecture
OTI Architecture
OTI Data Flow via API (Use Case 1) - consist of two components: OTI-event-proc microservice and OTI-handler microservice. This option not only can be used for real-time data collection, but also can support load balancing, auto scaling within the Kubernetes Cluster and Geo resiliency cross the regions (future release).
...
- MS must periodically look for files published under /otidata/process directory every 30 seconds (configurable) for the incoming OTI event update from sidecar. MS updates the Task.json/OTI_config.json based the event and does the collection based on Task.json.
- MS should select statefulset (sidecar) checkbox property during onboarding (to indicate to platform it will be deployed as stateful set/OTI solution).
- MS is updated to call CBS API to retrieve the KV_Config in K8s.
Option Use Case 2 - DCAE MS (e.g. snmp-polling) shall subscribe 'dcae-collection-event' via DMaaP-MR and use the provided information ( vnf/pnf name, collection ip, collection tasks etc) for data collection. DCAE MS shall publish the output data into DMaaP-MR.
Targeted Usecase (Frankfurt)
UC1a, UC1b and UC2a 
are targeted Use cases for Frankfurt.
...