[NETCONF-1093] Join yang resource providers from restconf-nb and yanglib into single service Created: 19/Jul/23  Updated: 19/Sep/23

Status: Open
Project: netconf
Component/s: restconf-nb
Affects Version/s: None
Fix Version/s: 7.0.0

Type: Improvement Priority: Medium
Reporter: Ruslan Kashapov Assignee: Ivan Hrasko
Resolution: Unresolved Votes: 0
Labels: pick-next, pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MDSAL-834 Support multiple schemas/module-sets ... Open
relates to NETCONF-668 RFC7895/RFC8525 implementation should... Resolved
relates to NETCONF-974 Support YIN sources in yanglib Confirmed

 Description   

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)

 Comments   
Comment by Ivan Hrasko [ 20/Jul/23 ]

IMO the restconf-nb is providing controller modules and yanglib is providing what is in cache/schema (YANG models downloaded from mounted devices).

Comment by Ruslan Kashapov [ 20/Jul/23 ]

the mapped URI for restconf-nb service is /rests/modules/(identifier.+)

the expected "identifier" is either (module_name/revision) or (path/to/mount/point/module_name/revision)
first retrieves model from global context, second from mounted device

the question to clarify how current service correlates to yang-library?

if yang-library is just generate URL to existing service when constructing yang-library data 
then we should make yanglib service a part of restconf-nb (no part of yanglib)
extending restconf service, just make a 3rd case parsing "identifier"

Comment by Ivan Hrasko [ 20/Jul/23 ]

IMO I would remove yanglib as it is. It reads YANG files from cache/schema and we need to restart karaf to see new models. I expect we will not have this kind of issues with data-store approach - using device's schema context.

Comment by Ivan Hrasko [ 20/Jul/23 ]

In fact, we should join this functionality in apps/yanglib-mdsal-writer as proposed by NETCONF-668.

Comment by Ivan Hrasko [ 19/Sep/23 ]

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.

Comment by Ivan Hrasko [ 19/Sep/23 ]

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}

Comment by Ivan Hrasko [ 19/Sep/23 ]

restconf-nb works for both controller's and device's modules, thus:

  1. remove yanglib bundle
  2. remove yanglib feature
  3. 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)

 

Comment by Ruslan Kashapov [ 19/Sep/23 ]

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.

Generated at Wed Feb 07 20:16:39 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.