...
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 | Committed | ||||
4 | Initial Inventory (semi hardcoded) | Committed | ||||
5 | Full (initial) data sync | Committed | 6 | Inventory Changes define and implement interface to add & remove cm handle | Committed | |
76 | Model discovery (get and store model for a cm-handle) | Committed | ||||
87 | Retrieve list of modules (names) for a cmHandle | Committed | ||||
8 | Full (initial) data sync | |||||
9 | Support dynamic inventory changes | react to DMaapP events using methods define under #5 | Committed | |||
10 | Read operations for single cmHandle, synchronous only | using 'pass-through' scenario (default on no data present for cm-handle) | Committed | |||
11 | Create, Update & Delete operations for single cmHandle , synchronous only | using 'pass-through' scenario (default on no data present for cm-handle) I don’t expect them to be different at all rom a NCMP/DMI plugin perspective | 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 | Implement -async option for CRUD and Patch operations | Out of Scope | ||||
16 | Support multiple cmHandles in a single call (bulk) | Out of Scope | ||||
17 | Support all cmHandles in a single call? | Out of Scope | ||||
18 | Support ds = operation-running for read and query operations | Out of Scope | ||||
19 | Support yang-data+json output format for ds = operational running | Out of Scope |
...