Rahul Tyagi Ericsson more lightweight, more experience. Available CSIT standard setup
Swaminathan Seetharaman mentioned 'Honeycomb' simulator they used before. Need to investigate if it supports get-schema method over RESTConf/NetConf
Need to check if we can use it with E2E NW Slicing model
3
Should (ONAP) dmi-instance be as separate (springboot) application Could be part of DMI Manager
DMI-Instance interface should be an open standard
Tony Finnerty and Team to allow easy integration of future 3rd part DMI-Plugin instances a separate application with its own REST Interface is required
Istanbul Roadmap
Priorities & Scope for Istanbul Release
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
If nothing is specified it attempts to read from the cache, if there is no cache then it will try to access the plugin
pass-through
operation-running (this means getting it from the cache if there is no data then you will get an error)
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
8
Model discovery (get and store model for a cm-handle)
Committed
9
Retrieve list of modules (names) for a cmHandle - make higher priority
Committed
10
Manual (initial) data sync
11
Support dynamic inventory changes (ONAP DMU Plugin)
react to DMaapP events using methods define under #5
Committed
12
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
If nothing is specified it attempts to read from the cache, if there is no cache then it will try to access the plugin
pass-through
operation-running (this means getting it from the cache if there is no data then you will get an error)
Committed
13
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
Stretch
14
Yang Patch operations for single cmHandle with ds = pass-through, synchronous only
Stretch
15
Retrieve list of cm-handles that have a given module
Stretch
16
Support yang-date+json output for all datastores
Stretch
17
Trigger (initial) Data Sync
Metadata (per cmHandle) controls whether this will happen or not
Out of Scope
18
Implement -async option for CRUD and Patch operations
Out of Scope
19
Support multiple cmHandles in a single call (bulk)
Out of Scope
20
Support all cmHandles in a single call?
Out of Scope
21
Support ds = operation-running for read and query operations
Out of Scope
22
Support yang-data+json output format for ds = operational running
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
Spike API for Update and Delete Operations
CPS-278
-
Getting issue details...STATUS