...
Data Model Inventory (DMI) consist out of 2 parts:
- DMI Manager (DMI registry?)Registry
- DMI Plugin (instances) DMI Instances e.g. ONAP DMI-InstancePlugin
Component Impacts; Suggested User Stories
...
# | Project/Component | Description | Suggested Stories | Comments |
---|
1 | CPS/NCMP | create rest interface on northbound for GET/POST/PUT/DELETE to access yang data. Note. Currently driven by "E2E Network Slicing" Use Case mix of CPS-CORE and NCMP Interface
| - Ensure all (CPS-Core) Read operations are mirrored
- Remove/migrate? 'hardcoded generic models used in H release"
- Spike API for Update and Delete Operations
- consider 'bypass' option
| - interfaces for yang data are: operational, intended, pass-through (selection can be done by enum)
check with netconf-sim if current nw slicing yang model can be imported including its imports.
|
2 | CPS/NCMP/DMI-Registry | Create dmi-registry. Data Model Inventory Interface (DMI) 'Internal service' no public Java or REST API responsibilities are - Store & retrieve cm-handle/dmi-since mapping in yang modelled CPS data table.
- include additional data (key-value pars as provided by dmi-service)
- Dmi manager is to select the dmi instance at runtime for cm handle for a northbound (write) request
| - create new module for dmi-registry
- create yang-model (ncpncmp-dmi-regsitryregistry) in cps repository for cm-handle->dmi-service mappingpluginmapping. To store relations between cm-handle (anchor) and dmi-service plugin (instances)
- Create anchor with model from step 2 in new (ncmp-admin) dataspace?!
(once upon deployment) - create API to
- create new dmi-service plugin entry during registration
- create API to
- Register cm-handle->dmi-service plugin entry when new cm-handle
- Get dmi-service plugin for given cm-handle
- Delete cm-handle->dmi-service plugin registration
- Delete dmi-service plugin ? TBC
| - separate stories for data and model.
|
3 | CPS/NCMP/DMI-ServicePlugin | Common standard (REST and Java?) interface for extensibility create dmi service for pluginfor onap. For production its responsibility of admin to provide instance of dmi. This story is mainly for testing purpose. - At first, on A&AI change event over DMaap, create mapping for cm-handle and dmi instance and sync yang model and data.
- Filter (register) only yang modelled xnf instances's cm-handle, based on event header information of Node
- dmi plugin instance (onap-dmi) have sdnc connector to access sdnc.
- call get/post/put/delete towards restconf interface (forward northbound write requests)
| - Defined and Agree common (java?) Interface
- create module dmi-onap-serviceplugin Rest and Impl modules
- create sub-module dmi-notification-handler
- create sub-module dmi-adapters
- create sub-module dmi-rest and dmi-serviceplugin
- create infra for separate spring boot application and docker image for dmi-serviceplugin
| - extract dmi-instance plugin into separate container consensus on rest interface is needed.rename dmi-instance->dmi-service
|
4 | CPS/NCMP | - enhance ncmp-cps interface (need to identify).
|
|
|
...