...
| 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 (NCMP) | sends an event with initial inventory (TBC) | Committed | ||
| 4 | Initial Inventory (semi hardcoded e.g. hidden rest endpoint or some kind of properties file, ONAP only) | Committed | |||
| 5 | Read operations for 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 | Committed | |||
| 68 | Model discovery (get and store model for a cm-handle) | Committed | |||
| 79 | Retrieve list of modules (names) for a cmHandle - make higher priority | Committed | |||
| 810 | Manual (initial) data sync | ||||
| 911 | Support dynamic inventory changes (ONAP DMU Plugin) | react to DMaapP events using methods define under #5 | Committed | ||
| 1012 | Read operations for single cmHandle, synchronous only | using 'pass-through' scenario (default on no data present for cm-handle) | Committed | In I timeframe ncmp will support the following datastore parameters
| Committed |
| 1311 | Create, Update & Delete operations for single cmHandle , synchronous only 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 rom from a NCMP/DMI plugin perspective | Stretch | ||
| 1214 | Yang Patch operations for single cmHandle with ds = pass-through, synchronous only | Stretch | |||
| 1315 | Retrieve list of cm-handles that have a given module | Stretch | |||
| 1416 | Support yang-date+json output for all datastores | Stretch | |||
| 1517 | Trigger (initial) Data Sync | Metadata (per cmHandle) controls whether this wil will happen or not | Out of Scope | ||
| 1618 | Implement -async option for CRUD and Patch operations | Out of Scope | |||
| 1719 | Support multiple cmHandles in a single call (bulk) | Out of Scope | |||
| 1820 | Support all cmHandles in a single call? | Out of Scope | |||
| 1921 | Support ds = operation-running for read and query operations | Out of Scope | |||
| 2022 | Support yang-data+json output format for ds = operational running | Out of Scope |
...