...
| Note | ||
|---|---|---|
| ||
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 on a particular installation.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
module gnodeb {
yang-version 1.1;
namespace "urn:gnodeb:test";
prefix gnb;
description
"Yang model for gnodeb";
revision "2019-12-03" {
description
"initial version";
}
container cells {
list cellinfolist {
key cell-id;
leaf cell-id {
type uint16;
}
leaf cell-uuid {
type uint32;
}
leaf cell-description {
type string;
description
"Possible name or description";
}
}
}
} |
...
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 :
| Info |
|---|
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. |
Alternatively, these can be tested via Postman as :
...
Check RESTConf fields filtering for examples on using filtering option on RESTConf.
Sample Some sample URLS :
...