...
| Priority | Description | Notes | Istanbul commitment |
|---|---|---|---|
| 1 | Publish and Share NCMP Rest interface proposal | detailed for Istanbul scope, general structure only for functionality related to later releases | Committed |
| 2 | Publish and Share DMI Plugin Rest interface proposal | detailed for Istanbul scope, general structure only for functionality related to later releases | Committed |
| 3 | Register a DMI Plugin (with NCMP) sends an | DMI plugin registration is implicit part of CM handle registration (inventory update), REST endpoint on NCMP (can be multiple calls event with initial inventory (TBC) | Committed |
| 4 | Initial Inventory (semi hardcoded e.g. hidden rest endpoint or some kind of properties file, for ONAP only)DMI plugin) | Additional properties for ONAP plugin may need ODL mountpoint, stored by NCMP and later provided to DMI plugin for each request. The mountpoint is created outside of CPS and DMI plugin. | Committed |
| 5 | Read operations for operational data (single cmHandle, synchronous only) | using 'pass-through' scenario (default on no data present for cm-handle) In I timeframe ncmp will support the following datastore parameters
| Committed |
| 6 | Create, Update & Delete operations for single cmHandle , synchronous only (fall back to plugin - this means your not specifying any datastore and there is no cache) | using 'pass-through' scenario (default on no data present for cm-handle) I don’t expect them to be different at all from a NCMP/DMI plugin perspective | Commited |
| 7 | Inventory Changes define and implement interface to add & remove cm handle | Related to (3) | Committed |
| 8 | Model discovery (get and store model for a cm-handle) | NCMP queries DMI plugin that provides information, for ONAP retrieved via SDNC/ODL | Committed |
| 9 | Retrieve list of modules (names) for a cmHandle - make higher priority | Used by applications to get cached information from NCMP about models | Committed |
| 10 | Manual (initial) data sync | Includes both NCMP and DMI APIs | Committed |
| 11 | Support dynamic inventory changes (ONAP DMU Plugin) | react React to DMaapP events using methods define under #5events from AAI sent over DMaaP, in turn using API in #7 for updates | Stretch |
| 12 | Yang Patch operations for single cmHandle with ds = pass-through, synchronous only | Stretch | |
| 13 | Retrieve list of cm-handles that have a given module | Stretch | |
| 14 | Support yang-date+json output for all datastores | Stretch | |
| 15 | Trigger (initial) Data Sync | Metadata (per cmHandle) controls whether this will happen or not | Out of Scope |
| 16 | Implement -async option for CRUD and Patch operations | Out of Scope | |
| 17 | Support multiple cmHandles in a single call (bulk) | Out of Scope | |
| 18 | Support all cmHandles in a single call? | Out of Scope | |
| 19 | Support ds = operation-running for read and query operations | Out of Scope | |
| 20 | Support yang-data+json output format for ds = operational running | Out of Scope |
...