Join yang resource providers from restconf-nb and yanglib into single service
Description
Activity
Ruslan Kashapov July 1, 2024 at 1:36 PM
yanglib was used to access device models persisted on local file system
the yanglib artifact was removed as solution for
https://lf-opendaylight.atlassian.net/browse/NETCONF-1068
see https://git.opendaylight.org/gerrit/c/netconf/+/110847
now device models are accessed from restconf server using in-memory source provider
nothing to optimize here, resolving as won't fix
Ruslan Kashapov September 19, 2023 at 12:39 PM
yanglib serves as remote repository, it provides yang resources from configured local folder.
accessing device models should not be treated as the only purpose of the service.
seems only testtool dumps own models to yanglib folder, but netconf-topology does not do it when real device is mounted.
so if yanglib is removed the remote repository functionality will be lost.
Ivan Hraško September 19, 2023 at 10:38 AMEdited
restconf-nb works for both controller's and device's modules, thus:
remove yanglib bundle
remove yanglib feature
adapt documentation with examples how to use restconf-nb instead of yanglib (replace https://docs.opendaylight.org/projects/netconf/en/latest/user-guide.html#yanglib-remote-repository)
Ivan Hraško September 19, 2023 at 10:27 AMEdited
If its not possible to get device's modules then design solution to use mount-point's DOMSchemaService to retrieve devices modules on path:
../modules/modules/network-topology:network-topology/topology=topology-netconf/node=17830-sim-device/yang-ext:mount/{module-name}/{module-revision}
Ivan Hraško September 19, 2023 at 10:22 AM
Please verify that we can read both controller's and device's models by restconf-nb's modules/module{yang-ext:mount} and remove yanglib.
Details
Assignee
Ivan HraškoIvan HraškoReporter
Ruslan KashapovRuslan Kashapov(Deactivated)Labels
Components
Priority
Medium
Details
Details
Assignee
Ivan HraškoReporter
Ruslan KashapovLabels
Components
Priority
Medium
Currently there two web services with own endpoints providing yang sources by module/submodule name and revision:
RestconfSchemaService(Impl) of restconf-nb
path: (host:port)/rests/modules/(name)/(revision)
content-types: application/yang, application/xml+yin
source: DOMSchemaService instance
YangLibService(YangLibProvider) of yanglib
path: (host:port)/yanglib/schemas/(name)/(revision)
content-types: application/yang, text/plain
source: local [karaf] directory with yang files
In order to make URLs and produced content-types consistent, and to simplify the maintenance it makes sense to join these services into single one.
Due to restconf-nb service also serves yang resources of mounted devices it seems reasonable to move functionality of yanglib to restconf-nb.
In order to differentiate the sources it makes sense to use multiple schemas (and/or module-sets).
Suggested URL then became (host:port)/modules/(source-id)/(name)/(revision)
where source-id will reference where the yang resource expected to be taken from.
It requires clarification either yang resources from a local folder (current yanglib functionality) need to be populated to yang-library data or it can be omitted as not a part of global context (similar to resources on mounted device)