[NETCONF-668] RFC7895/RFC8525 implementation should be independent of any other modules in a separate feature Created: 23/Apr/20  Updated: 15/Dec/23  Resolved: 19/Sep/23

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

Type: Improvement Priority: Highest
Reporter: Vladyslav Marchenko Assignee: Stephanie Brey Dee
Resolution: Done Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MDSAL-833 Support setting schema source URL by ... Open
relates to MDSAL-835 Provide deviations to modules data bu... Open
relates to NETCONF-1093 Join yang resource providers from res... Open
relates to MDSAL-834 Support multiple schemas/module-sets ... Open
relates to NETCONF-1196 Clean-up RestconfStateStreamsTest class Resolved

 Description   

Currently we have two places where RFC7895 was implemented independently (mdsal-netconf-yang-library and restconf-nb modules).  See SchemaServiceToMdsalWriter and SchemaContextHandler classes.
It could be an issue if we install these two modules together and they independently will change module-state.
This functionality should be independent of both modules in a separate feature and lives in md-sal, alongside of yanglib client implementations there. And both restconf and netconf should be pulling it to runtime as a dependency.

As a first step towards that, evaluate the content of netconf.git and create a apps/yanglib-mdsal-writer which both netconf-nb and restconf-nb will pull in.

 Comments   
Comment by Robert Varga [ 26/Apr/20 ]

So the long-term solution for this would be to have a separate, dynamic datastore shard, which would not need to be written but rather would react to schema being populated, and project that information as a datastore (i.e. similar to a JMX bean). The trouble is a bit clustered environment – DOMSchemaService is a local property, yet the datastore is replicated, hence ... yanglib really becomes a per-datastore (in sense of https://tools.ietf.org/html/rfc8342) thing and DOMSchemaService is really on its way out.

Unfortunately we are not there yet with the respective interfaces, so a simple split here, perhaps an integration with singleton-service and we could call it a day.

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