- CPS-395Getting issue details... STATUS
The purpose of this spike is to be able to identify the APIs we need in order to talk to SDNC for doing CRUD operations on the models that are mounted as nodes on a particular installation.
Assumptions
# | Assumption | Note |
---|---|---|
1 | rests bundle is pre-deployed | |
2 | NCMP/DMI-Plugin is not responsible for mounting nodes |
Issues & Decisions
# | Issue Description | Notes | Decision |
---|---|---|---|
1 | Bundle to use | It also supports actions. | "rests" bundle supports MIME type "application/yang-data+json" and is chosen as the bundle to use. Supports parameters like fields and depth (details below) |
2 | Differentiation between config false and config=true data | The NCMP and DMI interface will use the concept of datastores like 'operational' and 'running' to possible request config=true or all data. Currently it is unclear if the RESTConf/ODL parameter of 'content' works as intended to make this distinction. Currently on the simulator the available "datastores" observed are startup, persist and running. Rel I only aiming at non-NMDA devices. |
Spike Findings
Sample Model
For this use case we do not need to worry about creating mount points or supplying our models, as these would be made available beforehand.
For this spike we have used the NETCONF Plug-and-Play Simulator which enables the creation of NETCONF-enabled devices i.e, xNF.
To access local SDNC use - http://localhost:8282/apidoc/explorer/index.html
Credentials : - admin / Kp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U
Interface Usage
Once the above model is added to a mount point ( say PNFDemo ) on SDNC this model should show up on the GUI, with methods for operating on all public leaves as below.
where :
topology-netconf - is the topology
PNFDemo - is the node
gnodeb - is the model used
All of these are well documented with examples in the Swagger UI as below :
Postman sample URLs
GET all cells - http://localhost:8282/restconf/config/network-topology:network-topology/topology/topology-netconf/node/PNFDemo/yang-ext:mount/gnodeb:cells
PUT add/update cell - http://localhost:8282/restconf/config/network-topology:network-topology/topology/topology-netconf/node/PNFDemo/yang-ext:mount/gnodeb:cells/cellinfolist/{cell-id}
GET particular cell-id - http://localhost:8282/restconf/config/network-topology:network-topology/topology/topology-netconf/node/PNFDemo/yang-ext:mount/gnodeb:cells/cellinfolist/2
Filtering
This uses a different bundle (notice the URL).
For Field filtering we can use RESTConf "fields" option :
Check RESTConf fields filtering for examples on using filtering option on RESTConf.
Some sample URLS :
GET cell details - http://localhost:8282/rests/data/network-topology:network-topology/topology=topology-netconf/node=PNFDemo/yang-ext:mount/gnodeb:cells/cellinfolist=1
GET cell details with filtering - http://localhost:8282/rests/data/network-topology:network-topology/topology=topology-netconf/node=PNFDemo/yang-ext:mount/gnodeb:cells/cellinfolist=1?fields=cell-uuid
GET multiple fields with filtering - http://localhost:8282/rests/data/network-topology:network-topology/topology=topology-netconf/node=PNFDemo/yang-ext:mount/gnodeb:cells/cellinfolist=1?fields=cell-uuid;cell-id
Limiting subtree depth
For Field filtering we can use RESTConf "depth" option for GET requests.
The "depth" query parameter is used to limit the depth of subtrees returned by the server.
Data nodes with a "depth" value greater than the "depth" parameter are not returned in a response for a GET method
If the "fields" parameter is used to select descendant data nodes, then these nodes and all of their ancestor nodes have a "depth" value of "1".
Query Config data
The "content" query parameter controls how descendant nodes of the requested data nodes will be processed in the reply of a GET request.
Possible values are config, nonconfig and all, with all being the default.
Other available parameters :
Recording
Spike Demo Recording | 31/05/2021 |
---|