[sysrepo-devel] ?==?utf-8?q? new generation of sysrepo

Michal Vaško mvasko at cesnet.cz
Thu Sep 6 06:19:55 UTC 2018


Hi Andrew,

my comments are inline.

On Wednesday, September 5, 2018 21:08 CEST, ANDREW LANGEFELD <andrew.langefeld at adtran.com> wrote: 
 
> Hello Michal,
> 
> Below are a few questions and feedback on the proposed design:
> 
> > From slide 3: "No NACM":
> 
> Are there plans to move NACM support to elsewhere (e.g., to netopeer2), or will the feature be removed altogether? We would prefer to see NACM continue to be available as a supported feature.

Yep, it will be fully supported, but only for NETCONF (in netopeer2).

> > From slide 3: "No SR_EV_VERIFY?"
> 
> In the new design, will it still be possible for data subscribers to reject configuration changes, as is possible today? This is a desired use case that we would like to see continue to be supported.

It most certainly will be supported, we are just thinking about simplifying the callback design a bit.

> > From slide 15: Operational data subscription: xpath of the requested subtree
> 
> In the current implementation, sr_dp_get_items_subscribe() is limited to generic xpaths. Specifying list key values is not supported. Are there plans to improve this in the new design? In other words, will <get> <filter> content matches be supported? (This could improve queries for large lists.)

Yes, we are planning to support this.

> > From slide 26: Consistency example
> 
> We're concerned about this example. A second commit should not be allowed to start while a first commit is in progress. Instead, commits should be considered atomic operations. We do not want to rely on client behavior (i.e., acquiring a lock) for this scenario to work properly; the server should enforce the correct behavior.

We are trying to design new sysrepo to be efficient. If, for example, you have a model for which there are 2 clients subscribed and handling completely independent subtrees, why forbid them to process changes concurrently? I can imagine a solution where you would define whether you require implicit commit locks for a particular model during its installation (or simply make it adjustable some other way).

Also, I am attaching the slides with some minor updates and in PDF format so that it can be opened anywhere without problems.

Regards,
Michal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new_sysrepo.pdf
Type: application/pdf
Size: 1009202 bytes
Desc: not available
URL: <http://lists.sysrepo.org/archives/sysrepo-devel/attachments/20180906/ab1c5898/attachment.pdf>


More information about the sysrepo-devel mailing list